mqtt protocol vs webRTC - xmpp

What is mqtt and webRTC?
Where can I use them if I am developing a NATIVE mobile web application which supports voice and video chat?

You are comparing two different things.
MQTT is a messaging protocol for publish/subscribe that you could use to implement the communication between your native application and the back-end servers.
WebRTC is a standard that modern web browsers are beginning to support to allow a pure web application (HTML5/JavaScript/CSS3) to implement voice and video interaction without requiring any browser plugins (typically today such implementations require the use of Flash). Its worth pointing out that support in native browsers for webRTC is only now emerging (and still not supported on iOS). If you were developing a mobile web application you might choose to use webRTC to support voice and video in a platform independent way and then use MQTT over web sockets to implement the communications to the server.
Since you are developing a NATIVE mobile application, webRTC is not really relevant. As a native application you are not constrained by browser support.

Related

Suitable protocol for Instant Messaging

We have to develop a native mobile app for Instant Messaging using a SUITABLE protocol.
Also we are to develop a website for that application so that those who cannot login to mobile can continue their Instant Messaging through the website.
Later on, we would be adding the facilities of voice and video calls to the both native mobile app as well as the website.
Now my question is that, based on the above situation, which protocol we should go with?
I did some research on the internet about that and am unable to choose amongst XMPP, MQTT and MUMBLE.
Which one would be the best among them for the above criteria?
Also should I be using the same protocol for both the mobile app as well as the website? (no idea at all). Does choosing either the same or different protocols for native mobile apps as well as a website matter at all?
Consider me a novice here.
Your response would really mean a lot to me.
I am new to web development so correct me wherever I am wrong.
The answer to your question XMPP vs MQTT vs mumble really depends upon a number of factors that you did not describe in your question. Mainly on your non functional requirements.
XMPP is an xml based protocol originally designed as an instant messaging protocol. It has quite a high overhead in terms of number and size of messages in handling presence between all the clients. You could certainly base your implementation on XMPP. Google talk is based on XMPP and it uses XMPP to set up VOIP sessions using an extension to XMPP called Jingle.
MQTT is a general purpose low overhead publish/subscribe protocol. It is not specifically targeted at implementing instant messaging however Facebook uses it as the basis for their Facebook messenger. MQTT is a more efficient protocol in terms of its message size and its keepalive requirements so you might choose this if you plan to scale up to very large numbers of users or if you need your mobile clients to be highly responsive, even on low capability devices. If you choose MQTT then you will be left to design the "application level" protocol messages yourself, rather than following a standard. MQTT can certainly be used as the transport over which to set up voice chat and video streams.
You do not need to use the same protocol for mobile client versus website as long as your server side can appropriately process the interactions with mobile clients and web clients you could choose different protocols.
Facebook messenger does support voice messaging....
http://mashable.com/2013/02/21/facebook-voice-messages/

Is it possible to initiate a voice call from Mobile Safari to a proprietary service (i.e., not PSTN) with no plug-ins?

We assume the answer is no. However, all SO questions are either dated or based on desktop browsers.
We're aware of WebRTC, but it's not supported in Mobile Safari today. Is there any other approach?
To clarify the scenario, imagine we had a service like Skype. Instead of requiring both parties to have the app, we would like one side to use a mobile browser to have phone calls.
No, you cannot. Not without plugins. If you want to place calls from a browser to any other client, you must use WebRTC for full support (media transport + media devices access) or you have to use a plugin to access the media devices and to do the transport (e.g. Flash).
As Mobile Safari still don't have WebRTC...

Any advice for iPhone Wireless Comms with Embedded Linux Device?

I am looking for advice on protocols for use in LAN comms between an iPhone and an embedded Linux device. The embedded Linux device requires the following functionality...
Connectible to Wireless LAN.
Discoverable as a device on the Wireless LAN.
(Virtually) connectible with iPhone.
Remotely Callable API provided to the iPhone.
Able to remotely call back functions on the iPhone.
I am looking to use platform independent protocols to achieve this functionality because the mobile application will be ported from the iPhone to other mobile platforms like Android. Since I am a newbie with Embedded Linux, my research (and possibly naivety) suggests that said functionality could be realised with the following protocols...
DHCP for obtaining dynamic IP address.
DNLA? (Bonjour is native to iOS right?)
Connection-oriented communication implies TCP.
SOAP or REST architecture on HTTP.
SOAP or REST architecture on HTTP.
Can you suggest other, more suitable protocols? Am I barking up the wrong tree? Is there a much more simple way I could achieve this functionality? For example, providing the remote API using only a TCP socket?
Any advice you can offer is welcome...
Look into 0mq. It's a scalable messaging library that provides a message queue without requiring a message broker.
-Has objective-c bindings to help you implement in iOS
-Has java bindings to help you implement in Android.
-Small footprint.
I did something similar - an Arduino that streams data to an iPhone app connected over WiFi using the UDP protocol.

iPhone / Android: what protocol stacks do apps use for connecting to centralised services?

Aplogies for the ignorant question, I have no experience with app development on any mobile platform. Basically what I want to know is what communication protocols do apps typically use for accessing/querying centralised services? E.g if I port a webapp/service to iPhone/Android, typically how would I access/query this web service in my app? E.g is it over HTTP, or are there other protocols?
Also, presumably the GUI of an app is constructed with Apple/Android GUI libraries (in java? cocoa?). Can an app GUI be defined with HTML/javascript like a webpage?
Sorry again for the pure noob questions.
Thanks
Your question is pretty broad as you can really implement it however you want, but in my own experience the majority of "centralized" services are accessed directly over HTTP using an HTTP networking library or NSURLConnection. Most of the web services I work with are RESTful. Some people might implement with straight sockets, but that's just pain and would be best avoided if possible.
The GUI side is done using Cocoa Touch on the iPhone. I'm not sure about Android. You can certainly implement a web based app targeted specifically for iPhone. In fact there's been a lot in the news lately about developing HTML5 apps for the iPhone and iPad.

COM object to web service for mobile devices

We got a COM object for our web applications. now we need to develop application for different mobile devices like IPhone, Android and windows mobile. what are the options out there ( rest server, soap serverice ) any idea.
I highly recommend sticking with a REST service using JSON or a very simple XML for mobile delivery due to the bandwidth considerations for mobile networks. SOAP is too expensive a protocol for efficient mobile data transfer. In the case of iPhone, you will be hard pressed to find a SOAP library available.