I am using the ruby smpp library to send/receive SMS. Right now we are sending messages to two different servers, using the ruby-smpp library. One of them works perfectly, but the other one sends multiple DELIVRD confirmations for each messages. And by multiple I mean hundreds of confirmations per message in some cases.
Does anyone know any possible reason behind this? I am thinking on something relative to the implementation of the protocol the company is using, since it works perfectly with the other one, and not on the lines of a bug in the specific smpp ruby library. We are using smpp v3.4.
I haven't used the Ruby library yet, but I'll tap my basic SMPP knowledge to attempt an answer...
It sounds like you are asking for a delivery acknowledgement, but your server is not acknowledging the receipt of the delivery acknowledgement.
Page 31 of the SMPP v3.4 spec shows:
(you are on the left)
submit_sm ->
<- submit_sm_resp
<- deliver_sm
deliver_sm_resp ->
You could do a submit_sm without delivery receipt.
Related
I use SMPP routes towards providers, which have others providers in order to send SMS until the local operator.
My question is... How can I know how many provider hops there are in each SMS via SMPP?
I mean, since the SMS is sent towards the next provider until the SMS is delivered in the handset, does exist any way to know how many hops there are?
Could I add any information in the SMS in order to get this information?
I would like to get this information in order to know if the route is good or not.
Thank you.
With standard SMPP it is not possible to know how many hops (i.e. SMS gateways and SMSCs) there are between your application and the handset.
Monitoring the latency between submission by your application and delivery to the handset can provide a hint at there being multiple hops. This approach isn't reliable as high latency could simply be a slow single hop rather than multiple hops.
Asking your immediate provider how they route your messages can provide some insight. If they send directly to an SMSC belonging to handset's mobile network operator then you know that it should only be a hop from you to the provider and then another from them to the MNO. Probes, or your own testing, can be used to confirm if your message is being routed directly to the handset's MNO. In such cases you will see an SMSC address (SMSC GT) in the receive SMS that belongs to the handset's MNO.
It is not part of the SMPP protocol to know the hops to the final SMSC that delivers your SMS to the destination mobile. Number of hops does necessarily account for delays in SMS delivery.
If you will like to know if a certain route is good or not you could use other metrics like how many successful delivery reports have been received for SMSes sent via that route to build a table of good routes and bad routes.
Definetly not part of the SMPP protocol. For sure your sms won't be delivered via SMPP only, but also via SS7. The performance could depend on so many factors ... I think the best way to evaluate a 'route' is ( as other have said) to build some metrics/kpi's yourself and analyze them.
Please I'll like to know the difference between SMS and SMPP or at the very least get pointed to a good resource that breaks down this difference in layman terms. I'm currently on a project where the product vendor says the product only supports SMPP for inbound messages so it cannot be integrated to an SMS gateway. I've tried researching the fundamental peculiarities of SMPP that makes the integration with an SMS gateway for inbound messages impossible for this product but my research has yielded nothing material so far.
I'll really appreciate your feedback as the project is basically at an impasse due to the insistence of the vendor on SMPP.
SMPP is the protocol used to send SMS. Currently there are 2 ways to send a SMS. Either by SMPP (beneath the TCP protocol) or by SS7 (which requires hardware and is costly).
Usually SMS gateways are SMPP which is weird that you are not able to integrate it with it.
In brief, the SMPP protocol does the below:
Client binds to the server (Bind Request) / Server Accept or Reject
bind (Bind Response)
Client Sends SMS (Submit-SM) / Server accepts or Rejects SMS (Submit
Resp) server also includes the message Id
Server sends the DLR with the same message Id in the submit
response(Deliver-SM) / Client acknowledge the DLR (Deliver Resp)
Theres also an Enquire Link sent from the client and its response from the server to keep the connection from timing out usually 30 seconds.
Here's a link describing the SMPP Protocol in details:
http://opensmpp.org/specs/smppv34_gsmumts_ig_v10.pdf
How does Twillio get to send so many messages via SMS? I am thinking about making my own service for my company for internal use, but I am trying to discover how they managed to do that in such a large quantity while still remaning afloat? Are they using some sort of connection with a large set of phones, and automagically sending the messages from their actual devices? Wouldn't their service provider frown upon that kind of volume?
They are at most using SMPP protocol to send SMS messages directly to their service. SMPP is a protocol widely used for sending mass (bulk) SMS messages between third-party and operator.
Excerpt from Wikipedia:
The protocol is based on pairs of request/response PDUs (protocol data
units, or packets) exchanged over OSI layer 4 (TCP session or X.25
SVC3) connections. PDUs are binary encoded for efficiency. Data
exchange may be synchronous, where each peer waits for a response for
each PDU being sent, and asynchronous,
See full Wikipedia article: Short Message Peer-to-Peer
I may set up an SMS gateway using Kannel and a Huawei E220 GSM modem.
Now, my question is, is it possible for Kannel to detect extensions appended to the server's phone number in incoming messages (e.g. someone texts 12345#28 instead of 12345) and/or to send outgoing messages with such extensions appended?
Kannel supports deliver to recipient addresses with a '#' in them, but not by default.
By default Kannel's smsbox (HTTP I/F) has "0123456789 +-" as valid recipient characters. These can be extended to support '#' but setting
group = smsbox
...
sendsms-chars="0123456789 +-#"
That's all well and good but the key is does the underlying messaging layer you use for delivery support it also. For example when testing with a modem (kannel 'at' driver) - the modem returned an ERROR on the send command so it may also perform some addressing validation. Also when testing with kannel 'SMPP' connection to a provider the submit_sm request also returned an error. So Yes Kannel supports delivery to/from recipient/destination addresses formatted in that way - but that may be a moot point.
HTHs
Cheers,
Alan
I read that a GSM modem can only receive up to 30 SMS per minute. What would you do if you need to receive more than that? Is there another technology?
I think you might want something different to those answers listed at What are the best practices for building an SMS server
If you just have one service that is running where you want to receive many SMS then it would be most cost effective (and simplest) to avoid integrating with a mobile network operator and instead use a SMS aggregator. These often call themselves SMS gateways, but they are independent companies and not a mobile network operator's gateway.
An SMS aggregator acts as a middle man between you and the networks - they have agreements with many network operators and this interconnection means you can link with one aggregator and get access to almost every network in the world.
Aggregator's usually advertise for outbound SMS (where you are sending an SMS from your application to a user), but they all offer inbound SMS as well. Depending on your country you could opt for a premium number or free to receive number. A premium number would mean that the person sending the text message would pay extra money to send you a message - you may want this for a commercial service in order to bill the user. A premium number would also mean you receive a share of the money the user paid to send you the text message. A free to receive number would not cost the person sending the text message anything more than it would normally cost for them to send an SMS. Almost all aggregators will charge you a monthly rental for a free to receive inbound telephone number, but no additional charge per message received.
You can expect to integrate with an aggregator using HTTP or SMPP. HTTP is usually the easiest and the aggregator will want to know where to send the HTTP post when a message is received on your telephone number. Therefore you will need some sort of service that is running to receive the HTTP post from the aggregator, and possibly a way to reply to the user by sending another HTTP post back to the aggregator asking them to forward a message to the user confirming receipt of the inbound SMS message.
SMPP is a more robust protocol and is often used for high volume SMS applications - unless you already have SMPP experience or are sending many hundreds of thousands of messages you may want to avoid SMPP as it is difficult to implement until you have a lot of experience with SMS.
Some aggregators will provide their own platform where you don't need to have your own service running. For example you could setup a simple "autoresponder" on an aggregators website, this would receive the inbound message from the user, then autopmatically respond with a "thank you message". All interaction is done by the aggregator and you can log on periodically to download statistics or look at the messages people have sent.
Popular aggregators are:
InfoBip
Silverstreet
mBlox
If you do not have your own platform for managing the SMS interaction then either use the aggregator's own platform of install your own SMSC gateway. Some SMSC's are:
Kannel - Open Source, fairly difficult to install and manage.
NowSMS - Commercial software. Powerful, windows only, easy to use SMPP integration and has a 30 day free version. Allows GSM modems, HTTP and SMPP integration. Most expensive of these options but pricing is based on number of messages you want to send OUT per second / minute so if you're not planning on sending many out and only receiving them maybe this would be a viable option. There's a cheaper version where you can use one GSM modem (mobile phone) connected to a computer with a USB lead but as you will only have one GSM modem and no aggregator's you are limited to the speed at which your device can receive inbound SMS.
Ozeki - Commercial software. Lots of documentation available and the support team are very responsive. You can add local GSM modems or aggregator's using HTTP or SMPP.