I have an idea for a mobile service based project. I have read some stuff online, including the following tutorial: SMS Tutorial and find it to be pretty helpful but I have some basic questions so please bear with me.
I run a small (as in me and a friend) company and want to setup a situation where people can text a number and receive information back, or setup on my website that they receive text messages letting them know its time to do something, or "tech support" can text them if they wish, etc.
So from what I've gathered, I can use Kannel as my "SMS gateway" interacting with a GSM Modem that I can purchase. For this modem I can buy a texting plan SIM. I can then setup Kannel to use my GSM modem as a virtual smsc. So, users can text that SIMs phone number, which will go to the modem and be interpreted by Kannel. My application will only have to interact with Kannel. And in the future, if I decide I need more texting throuput and upgrade to a real SMSC my application does not need to change.
Is there anything I'm missing/misunderstanding?
Thanks!
Using Kannel as a SMS gateway is a good option for a small company. It does come with a lot of headaches as you have to build, configure, maintain, etc.. all of the services you need, This is what everyone is referring to as "A lot of work".
What you are looking to do is use the GSM modem as a Long Code (verses short Code) for text messaging.
I think this is an expectable solution for something small and where service, latency and availability might not be as important if it's for a local region. But if this is something that needs to be reliable I would think about getting a short code (or sharing a short code) or just a SMS Messaging service with No Long/Short Code (See Twilio Below).
Also if you're trying to rollout your own service there are some things to consider with the SMSC's. If your Kannel/GSM Modem doesn't support the Carrier, you would have to reach out to that Carrier and connect to thier SMSC. This is a hefty price to connect to a Carrier. This is way Aggregators are appealing as they Have all the Carrier connections and pay those fees.
As you transitioning from Kannel to a Gateway Service Provider, that's another headache as you would need to start from scratch and use whatever the service provider API is and replace the Kannel/GSM altogether. Your workflow might be the same but how you send and receive messages with differ greatly. Most (if not all) Aggregators will offer there own version of a SDK/API/Service that you would need to comply with to use their service.
If it's in the US there are some other options you might consider:
Twilio, this is the simplest solution I've seem for smaller companies looking for SMS functionality. Now they are currently offering SMS Short Codes by trial but if you need a short code I would go with a true messaging aggregator.
Zeep Mobile Offers a free SMS service with a Short Code, but they do send Ads with all your SMS Messages. This is a great way to subsidize costs if the Ads don't bother you. Not sure if you can pick the types of ads you want but it's another option for a service.
Clickatell offers a service where you can Share a Short Code and use Keywords to filter your SMS traffic to your account. This is another way to cut some costs if you're funds and traffic (how much SMS you send and receive) are limited
OpenMarket offers a full service SMS/MMS global platform, this is who you want if you doing Mass amounts of trafic and/or need to reach globally.
Note: These are just a few services as there are many, many more
There are also some caveats with having a Short Code as you will need to register a new Short Code if the country you are services needs it's own Short Code. Example: you can use your US Short Code to service Canada, You would also need a Canadian Short Code as well. This can get costly if your only doing small amounts of traffic.
I think you have got basic considerations. John is right, and using a sms gateway is better idea, you will get better reliability and thoughput. And you could get slow prices.
Related
mux.com (and also agora.io and so on) is a great service, but very expensive since it's a server solution. I can't use that.
Discord is a great client solution, that just uses gateways as a pass-through to hide IP addresses and so on. They described their entire architecture here: https://discord.com/blog/how-discord-handles-two-and-half-million-concurrent-voice-users-using-webrtc Discord ain't the only one with this approach, Instagram has AFAIK the same approach too, since it's cheap and does what it does
I want to use for my social media app (like instagram) this solution too, but without these many custom built things to increase performance. I am a one-man team and I can't handle that complexity; still i don't want to use mux because it's way too expensive for me
I am okay with the stock/standard performance. Does anyone know or can point me to a tutorial, where to start building such webRTC elixier gateway solution for m:m audio/video live streams calls?
maybe there already is code published that I can just copy paste
thanks a lot!!
edit
ive got an answer on their official forum https://elixirforum.com/t/how-to-build-webrtc-m-m-audio-video-live-streams-calls-like-discord-does-client-to-client-via-gateway-for-ip-protection/44956
Discord backend use SFU to forward streams for peers in a videoroom, the description from the discord post:
Discord Voice server contains two components: a signaling component and a media relay component called the selective forwarding unit or SFU. The signaling component fully controls the SFU and is responsible for generating stream identifiers and encryption keys, forwarding speaking indication, etc.
Note that the projects in answer are written in Elixir(based on Erlang) programming language, which is not very common used in neither live streaming nor WebRTC. For example, FFmpeg, x264, libopus, WebRTC, SRS, all these audio/video components are written in C++, you'd better think about it.
For a video chat product like discord:
The client app, no doubt, could be built on WebRTC, both H5 and mobile.
For SFU server, recommend C++ server, for example, SRS or mediasoup. Because the whole audio/video economy is C++ based, there're lots of stuff to handle for SFU.
About the signaling server, also called videoroom, could be written by nodejs or Go, because it depends on your business, so highly recommend your best skilled language, there're lots of work to do in this server.
And not all peers in a video room need to publish video stream, instead they only play or consume streams, so it's actually low latency live streaming. For more information about live streaming and video chat, please read this post.
For a hobby project of me i'm looking to implement a group voice chat feature. Pretty straight forward: I'm running a server to which multiple clients (mobile) can connect to. Some Clients are in the same "group" and I want them to have an audio chat feature.
I already set up a UDP server client with C# to which clients can connect to. I have successfully implemented audio distribution between clients over the server and the rudimentary features are working pretty well.
I am not sure if i'm going in the right direction with this approach though.
I'm stuck with the implementation of mixing the different voices for example (two people talking simultaneously and another is listening to both). I don't really know how I can mix both voices together and generate different outputs for different clients - above mentioned example: The two people talking should only receive the input of the other person while the one not talking should receive a mix of the other two talking.
What is the best server sided structure for this? Should i maybe go in a completely different direction and work with SIP? I'm having a hard time finding suitable resources for this problem online and i'm really stuck.
Thanks for your help!
Let me suggest using standards in your application. If (as I strongly recommend) your application is a web application, WebRTC make your job dramatically easier. Please see in WebRTC samples some ideas that I'm sure will inspire you, including multiple peer connections
If you are only interested in group calls, you could install a PBX server as asterisk that has a powerfull set of conference capabilities. You could use a SIP library on top of WebRTC in clients (e.g. sip.js, sipml5) to connect via SIP to asterisk and obtain conference services. This could sound daunting but the code for calling a conference room can be reduced to very few lines and asterisk can be easily installed in a linux box in a real machine, or in a virtual one or in a docker container.
If you prefer fat clients, I suggest using a SIP library as PJSIP (that incidentally is the base of the new SIP stack for asterisk). Proprietary solutions ride against the future while standard ones are pushed by it.
Does anyone know of any documentation of how to access bank data via some sort of webservice or other method for use in a Silverlight financial / banking application? Is there any sort of standard protocol or terminology used for this that I can look up online. I'm having trouble finding any sort of information on how this is typically done.
"Access bank data"... Not exactly something banks allow from the outside world. They kinda want to keep things secure :)
If you work for a bank you may well have access to various web services internally. There are standards for data transfers, but every bank will likely have it's own systems.
I'm having trouble finding any sort of information on how this is typically done.
That's probably a good thing. This is typically done by either internal bank developers or consultants. For example, take the Bank of America Windows Phone 7 app (which is a Silverlight app): it connects to BofA's servers, but I would be surprised if the way in which it connects is public information. Because you can use it to check your account, I can only presume that there is a web service hosted somewhere that allows these clients to get this data. I'm pretty confident, however, that the connection is secured, and the details of it are kept hidden for good reason.
In short, banks don't usually expose web services to the outside world for public consumption. Unless you've been hired by a bank to specifically do this, I'm not sure you should be able to.
I have email notifications on my site but I want to add SMS notifications also. I am lost how to do this. Is it purely coding or do i need to engage in partnerships with phone providers world over or buy a service or how does it work. And for the coding are there frameworks i can use or have to do it from ground up? My social network is in php and mysql. Do i need anything from the database for this, like to store the messages or is that all on the ISP's end?
You need either a service for that, or to set up your own infrastructure (GSM modem, etc.). Best go with an SMS Aggregator, such as Clickatel. The technical term for this kind of service is "SMS Gateway".
Whichever gateway you choose, you need to find out what their API is and use it to send SMS.
I recommend Twilio. I used them to send SMS and synthesized voice notifications for an agricultural telemetry monitoring application I developed, and in my experience they have a fantastic service at a very reasonable price. (If I sound like a shill, I'm not -- just a happy customer.)
As for integration, they have a REST-based API that's easily used from PHP. I think they even have a PHP library, although I haven't used it myself.
You need to sign up to a SMS gateway. There are very many SMS gateway providers out there. You need to write code to send the SMS, quite similar to the code you write for sending e-mails. Fortunately you can re-use code written by others for this.
I have good experience using Clickatell as SMS gateway and they have code for sending sms ready for several languages including php.
You do not need to store anything in your database, fire and forget.
Good luck :)
Many telephone companies also operate free email-to-SMS gateways; for example, T-Mobile has it setup where you can send to phonenumber#tmomail.net to send an SMS/MMS message. Of course, it is less efficient and also requires that you know about all the gateways out there (and keep them up-to-date as possible, of course). However, it's an option if you have only a small number of users, and/or a large number of users that are on a small number of separate networks.
You have two main options when it comes to adding SMS functionality t your website or blog. 1. Cloud based SMS gateways 2. Software based SMS gateways
Informs of initial setup Costs and time required to set up the service, cloud based solutions are preferable as their popularity means there are many who use the service and provide hell on their forums - normally only a little knowledge of html you could be up and runing within a few hours
The following website has some useful info on the subject and also provides a free international SMS widget for webmasters to add SMS to their websites or blogs
http://xboxpcpro.co.uk/how-to-add-sms-to-website/
I want to transfer data between a smart phone app and a website. What are the conventional and not-so-conventional ways of doing it?
Here's what I have thought of so far:
Simple HTTP GET/POST with data being represented as JSON array string, variations of this being encrypted/compressed string as parameter.
Webservice calls ( I am not sure if this is even possible, just a guess)
Two step communication : Smartphone to/fro Desktop App to/fro Website) (Cumbersome to develop/use)
Also, what do I need to consider to avoid spamming/snooping?
If your goals is convince, security and ease of development. I'd have the client (phone) make requests to the server over HTTPS using POST. The data sent should be what ever library is available for your target system. Good choices are URL Encoded parameters, XML and JSON. Avoid Binary protocols.
The downside of this approach is using network connectivity from a device to the web service may not be available or expensive, with the plan the user has. (this is becoming less so with the current wave of smart phones (iPhone/gPhone/Blackberry etc))
This is also a polling interface, so pushing data from the server to the handset is tricky and dependent on the User initiating some action.
Depending on the phone platform, you could also use SMS, for bi-directional communication. The limitation here is privacy, bandwidth and cost. SMS's are more expensive to send the ip data depending on user plan. (and sometimes to receive) The bi-directional trick is performed by registering a SMS hook in the phone application. Thus the application can be automatically started and notified when a certain SMS is received.
Please post additional information, like target platforms and I can discuss further options.
I think the first two are pretty much the same thing. What you want to do is an HTTP Post if you are sending a lot of data, or a GET with a query string if theres a smaller amount of data. It's all going to be unencrypted transmission, so keep that in mind when using HTTP.
If you're using the .NET Compact Framework and developing for Windows Mobile, the easiest approach is to use web services. However, .NET web services serialize everything as verbose XML, which makes the size of the data sent back and forth larger than it has to be. Using JSON is a good way of cutting down on the size of your data, even when using .NET web services (the trick is to send an entire JSON document as a single parameter). Minimizing the size of your transferred data is especially important for Smartphone applications, since your data transfer will probably be done over a cellular network.