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
Related
I use Kannel as SMS gateway - It works fine for me. I am connnected one operator and I provide SMPP COnnections to my clients. All works fine.
But now I need to filter the traffic based on the recipient number ie I need to be able to set a REGEX for the receipient and reject the SMS if it's supposed to be sent to those recipients.
Is this possible in Kannel? Any idea of how this can be done?
Thank you.
Core group configuration (i.e. bearerbox configuration) has parameters for white-list-receiver-regex and black-list-receiver-regex, those should do what you're looking for. That is, however, a system-wide setting, not a per-SMSC setting so it applies to all numbers through all SMSC connections.
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
Does CDMA support concatenated SMS?
If it is does which version of CDMA added support for it?
Which networks in the USA that use CDMA support concatenated SMS?
Thanks!
I wrote a blog post about this a while back:
https://www.smallbusinesstech.net/concatenated-sms/
Basically, Verizon only fully supports concatenated SMS within their own network. When sending out from Verizon to another network concatenated SMS works correctly. Concatenated SMS messages sent from another network to Verizon are delivered as individual SMS messages.
Sprint does not support concatenated SMS at all.
By "long" SMS, do you mean EMS? EMS is a series (varies by carrier), of SMS messages "stitched together". Your phone receives N messages and presents them to you as a single object.
However, as noted, this is both device and carrier specific. Your device is built to your carrier's specs for EMS. THe major US carriers support EMS, but the details vary.
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.