VoLTE is a relatively newer technology. I understand that calls made using VoLTE use internet data (The same data that we use to browse the internet, watch YouTube videos etc.) It kind of fascinates me. I tried getting more info about how it works and came to know that VoLTE is something like an "optimized" data network for Voice (Which makes it much better than VoIP). My question is:
Q. 1) If it is "optimised" data network, then how come we make VoLTE calls using the same general purpose internet.
Q. 2) Is the optimization done on the client side.
If YES for Q. 2), what are those optimizations and how to use them in an android app. Is there any library for it? (For Ex. This)
Q. 3) Also, does VoLTE means an end to VoIP and hence an end for Skype, Facetime etc.? Can Skype or Facetime port their mobile apps to use VoLTE over VoIP?
In a very general sense, yes VoLTE does use "internet data" like Youtube, etc, whereas traditional voice calls are circuit-switched.
However, LTE uses a QoS mechanism to prioritize VoLTE so that it is not treated the same as data coming from your web browser, etc. You can see from the standard QCI table below the properties of different bearers (logical connections):
While your typical web browser will use QCI 8 or 9, a VoLTE call will use QCI 5 for control plane signaling and QCI 1 for the actual voice call. This ensures that a tighter packet delay budget is used and the bitrate is guaranteed. This is mainly a core network functionality, however the end user device (UE) must be able to support it. You cannot change the QCI of the device from the client side, it must be changed in the HSS (Home Subscriber Server, a core network component).
With regards to your last question, Skype and other similar applications are considered OTT (Over The Top) applications which are treated like normal QCI 8/9 applications and not given any special priority. So, what this means is that if you are in good coverage on a non-congested cell (and core, etc) you may not notice a difference between a Skype call and VoLTE call. However, if you are in a coverage- or capacity-challenged area, the VoLTE call will be superior. Finally, I do believe there are some operators that have built native apps that can take advantage of the various QCI profiles.
VoLTE is almost same as VOIP, only difference here is where the data flows(LTE or Ethernet/Wifi). You can say VoLTE is evolved from VOIP.It does not mean that it is an end to VOIP.
SIP signalling in VoLTE will be over dedicated bearer or PDN of QCI 5.
Since LTE IP based(Packet switch) network, your SIP signalling and Voice data(RTP) is transmitted as IP packets in different bearers. It is the NW/operator who decides the priority for this dedicated bearers. So Internet data will have different priority over the VoLTE data.
If you have any SIP application , you can configure it to use the INTERNET PDN/Bearer for the SIP signalling and media. This will be treated as internet data.
Optimization is with respect to codecs used in the client to for the media. You should have bandwidth efficient codecs to support.(LTE protocol(PDCP) takes care of optimizing your IP packet including UDP and RTP packet of the media.
If your VoLTE call is using qci-5 and QCI-1, then data of VoLTE will given more prio. But VoLTE calls will be generally charged from the operator.But skype will not charged from the operator. SO you can guess whether it is an end to skype or not.
VoLTE technology is not just the device side , it includes Carrier's Infrastructure as well . Even if you use same signalling (SIP ) and media (RTP) protocol , Unless you use bearer specified by operator negotiated in NAS and RRC signalling , it will all be treated as just other internet traffic and will not be eligible to have dedicated bandwidth for the duration of call . You will also miss out on any Supplementary Services that your Carrier Provides. This all makes more sense if you are mobile and may have fluctuating network , In Ideal conditions , quality offered by VoIP applications may be same or even much better than VoLTE call quality.
Q. 1) If it is "optimised" data network, then how come we make VoLTE calls using the same general purpose internet.
we dont , there is a negotiation between network and handset for a channel with guaranteed quality of service , ie in bad network , this data will be dropped last.
Q. 2) Is the optimization done on the client side. If YES for Q. 2), what are those optimizations and how to use them in an android app. Is there any library for it? (For Ex. This)
This is done in ODM (phone makers) software after following specifications and certifications from Operator Body (GSMA like) . There is no lib for this , One can invoke android telephioy framework but that will essentially be same as using dialer
Q. 3) Also, does VoLTE means an end to VoIP and hence an end for Skype, Facetime etc.? Can Skype or Facetime port their mobile apps to use VoLTE over VoIP?
Facetime , skype etc are called OTT apps , whereas volte calls are native apps . You may consider Volte calls as something which violates net neutrality but as its in compliance with government rules , its considered to be ok.
Related
For android phone which supports volte, they can directly place call with jio sim without data require, but the phones without volte needs to use Jio4GVoice app or a custom rom which supports volte to make phone calls.
IS there any way , we can implement it for offline use?
4th Generation network, which we also know as LTE, was developed forecasting the growing data needs of the future. It was intended to replace wired broadband with wireless devices, a platform for which had already been set with 3G networks.
Hence this time, their focus in the development phase was not Voice, but only Data. To simplify network designs, all communication in & out was to be handled on fully-IP networks, much like the present Internet. This would enable faster, simpler communication than 3G, since all communication is now referred with their node's IP addresses. It was only in the final phases of development that they practically realised, for 4G to completely replace legacy systems, they must find a way to transmit Voice over the network, which they succeeded in, with VoLTE.
Basically, VoLTE speaks for itself, i.e. Voice over LTE.
VoLTE transmits Voice in Data form, much similar to VoIP internet calls we make on WhatsApp or Skype or Google Voice.
This means, you always need to establish a Data network with your respective 4G operator. This is unlike the system established in 2G/3G networks, where it would establish data networks only when you needed to surf the internet. Those were based on two way systems, different for Voice & Data.
4G transmits both Voice & Data simultaneously over the same Data pipeline, so you have the right to only be charged in Data you consume & not Minutes you talk. Which is the reason why Jio does not charge you separately for calls. The bandwidth required to transmit Voice is very small, (most calls usually fall in the range of KBs, in standard plan you get 1GB per day) & so Jio deducts the data used for Voice from your Data balance.
Since everything is data, you need to establish the data connection on your 4G smartphone or JioFi router to make calls. Hence Jio4GVoice app cannot function without a data connection.
I've seen in various VoLTE enabled smartphones, they still give you a Data Toggle/Switch to turn on/off data so that you can conserve some when not in use. It does not physically terminate data communication with the network, since it is the only connection. Rather, it just isolates all apps on your system from accessing the internet, and only the Dialer is given access to continue to make & receive 4G VoLTE calls.
Hope I've managed to solve all your curiosities.
I want to ask some question regarding the development of my push-to-talk application for Android.
Recently, I've been developing push-to-talk Apps for Android. I use DatagramSocket to send voice and receive voice as a Packet over Local Wireless network (W-LAN). I use peer-to-peer network, so no server.
I don't have a problem with the code, but I don't understand the basic of VoIP theory, so I want to ask some question, hope somebody can give me simple answer :)
1. Is my push-to-talk Apps considered a VOIP-based?
2. There is several VOIP protocol such as SIP, H.323 and many more. If my PTT Apps considered a VOIP-based, and I use Socket-Packet (UDP, am I right?) to exchange voice, then what VOIP protocol that I use? Is it considered RTP protocol?
I would like to understand the theory behind my PTT apps, I understand my java code, but I don't have proper VOIP knowledge.
I've tried to find some information in google, but I still don't understand what is the relation between my PTT Apps and the VOIP technology.
Thanks before, I'm new here and sorry for my english!
I. "VoIP" is a very broad term, but, if your app transfers voice over IP network, it's definitely VoIP one, despite it may use totally proprietary protocols (as e.g. Skype does).
II. VoIP stack is basically split to two meta-layers - 1) signaling and 2) media transport. Each of them is in turn consisting multiple own layers (e.g. for SIP: session, dialog, transaction and transport layer). Examples of signaling protocols are H.323, SIP, MGCP. The most standard media transport is RTP. You can use your own transport; RTP applies specific restrictions (as AVP profile) but is compatible with variety of libraries and other implementations.
There are protocols which use the same socket and the same transport type for both signaling and media; the widely used one is IAX. Most others separate signaling and media, so sockets are separated and likely they have different type. A standard-compliant SIP implementation shall function over both UDP and TCP, and switch to TCP for large requests (>=1300 bytes by default); SCTP is also suggested. For all transports, protocol implementation details as retransmission policy and request timeout are specified in different way, but there is no principal problem with using any correct L4 protocol.
The totally another story is with media transport (under RTP or equivalent). Here, typical TCP manner to transfer all data at the cost of floating delays is really nasty for our ears. TCP is good for bulk traffic class, as file transfer or database interaction. In interactive communication between humans, we prefer more noise and sporadic voice loss than a voice strain. So, TCP is a very bad choice here, and a synchronous transport class shall be used, and UDP is the good default choice. SCTP can also be used as media transport, but with limited retransmit option (not all stacks support it). (There are attempts to use TCP to punch through NAT points but all this is an act of despair.)
If your application supposes sending a voice message more than to one recipient at a time (i.e. a kind of broadcast or multicast), this rejects use of connection-oriented media transports, effectively retaining only UDP. This also requires proper negotiation at signaling level.
III. Selection of voice codec is very platform-specific, I don't use which ones are native for Android. In "big" VoIP, there are licensed set and free set, with very small intersection (AFAIR, G.711 and GSM). Despite this, there are good codecs (e.g. Opus) which can be adapted into wide range of requirements, including partial packet loss.
Let's say I have an Android device which supports GSM 800/900Mhz bands and I want to use it as a transmitter to remotely control a car or anything else.
Is it possible to program such a thing on Android ? Maybe using NDK ?
The purpose would be to send custom packets on these frequencies.
Thanks.
There are a lot of misunderstandings in this concept, however what you're thinking of quite nice, assuming it would be possible (which isn't :( ).
RF communication is handled EXCLUSIVELY by the modem software, which is included in the baseband binaries.
You cannot simply tap into it, and send whatever you like, since the protocol and its transport layer are very strict to comply with the GSM rules.
Also - since baseband binaries are under strict control there are very few, to none custom ones.
There are also WAY many other reasons why this is not actually possible, without lots of hackish work. Those devices are made strictly to perform on the GSM network. You could use another reciver to for example send WAP push messages (in raw form) as commands, however expect the delays to be HUMONGOUS (ie. 1second - 20 seconds) which is not viable for any kind of remote control. Same results as SMS communcation, just in an unrestricted form.
CAUTION: Using telecom broadband channel is BANNED for public use in most countries, so even if you get an external GSM bands transmitter (which actually can be done), you still would need to comply to your countries regulations.
Possibly related thread: https://electronics.stackexchange.com/questions/94668/longest-range-remote-control
I need to either get an actually TCP connection between two android phones or minimally the ability to do a 4 step order dependent protocol ( A sends to B, B sends to A, A sends to B, B Sends to A) with small payloads (at worst 20kb per message )
This needs to work
without wifi, bluetooth, or nfc enabled (i.e. over 2/3/4G)
between Andriod phones and preferably between and Android and IOs as well as between iphones
Not require a third party server and preferably not require me to run a server
I am perfectly willing to make someone scan a qr code to "pair" the phones or exchange basic identifiers.
Is there anything better that I can do other than setting up my own server and running some network hole punching solution to open up a TCP or UDP stream between the two devices?
If there isn't, whats the best network hole punching solution for android?
What seems not to work:
Googles C2DM push notification seems to be meant for server to device messaging to trigger a pull.
Alljoyn seems to do exactly what I want in terms of messaging, except it appears requires users to enable wifi or bluetooth. The idea is to avoid using the cellular modem.
Android natively supports this for WiFI via this api, but again this is a non starter.
Finally, there is the Bump api , which does almost everything I want but requires a third party server. This is a no go on privacy grounds since the server learns when people use the app.
I'm currently working on an android project and I am trying to find the best way to go about setting up communication between two android phones.
One android phone will be docked on a mobile platform e.g. an R/C car. I want this phone to receive simple control signals ("forward", "backward", "left", "right", "gotoCoordinate") sent from another android phone. I also want the docked phone to be able to return status signals.
Preferably I want the communication to happen via GPRS. I'm aware of the difficulties concerning P2P-communications and I'm currently looking into "Android Cloud To Device Messaging." (http://code.google.com/android/c2dm/index.html)
I'd like to hear about your experience with Android C2DM (glad to hear about delay from transmit to receive) and your thoughts on utilizing it in my project. I'd appreciate other suggestions on how to go about this. I'm expecting to have to deal with relatively high latency using this method, but of course preferably lowest possible.
C2DM makes no guarantee about the "delivery or order" of the messages, and it is limited in the number of messages you can send (a high limit, but still a limit). It's not really for low-latency stuff like controlling an RC car. It's better for non-realtime events.
http://code.google.com/android/c2dm/
For lower latency stuff using GPRS you can setup a third party server on your own and have both phones communicate through it. I've done that for several Android apps using straight up TCP sockets and it works reasonably well (and it would be even faster/better if you went UDP). Using GPRS may still have too much latency, depending on your needs, but it's a tradeoff (it's very convenient, almost always there, other methods are not).
The ideal way to do this would be to combine whatever is available and fallback gracefully, and test the latency once connected to make sure the network is up to par, or bail out. For example, use the local WiFi network if it's available. That is to say, have both devices "register" with a third party server as they startup, then if they're both on the same WiFi just have them communicate directly (run a server on or both, and clients on one or both, get information about discovery and such from the registration). If they are not on WiFi then fall back to GPRS, but realize there will be more latency, of course. Finally, once any method has been established send some test messages to check latency.
I know this isn't really an "answer," it's more of a stream of consciousness about this, but it wouldn't fit in a comment, and I thought it might help ;).
(Full disclosure: I've worked on Android apps that connect multiple mobile devices and multiple TVs, some over GPRS, some Wifi, some directly. I work for a company (MOVL) that makes a platform for stuff like that, it's more focused on mobile-TV-mobile, but it supports mobile-mobile also. In all it's not too hard to do yourself with regular networking, the tricky part is getting the latency down and picking the correct method for each device.)