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.
Related
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.
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 am implementing a real time - multi user voice transfer application for Android.
I have read that, as a standard - RTP packets are encapsulated into SIP and then sent to destination(s). What is the advantage of doing so?
my idea was to use a server, just to receive control messages from nodes and open sockets. All these nodes would be in 1 group. THen, I send out the IP addresses of each of these nodes, so that a single sender can multicast its packets directly to the destination.
is there a fatal flaw here? ( iam not concerned about the power consumption)
How does SIP do better? or does it ?
Thanks
RTP isn't "encapsulated into SIP packets". SIP is a signalling protocol. RTP is a media stream protocol. SIP is used to negotiate and set up (and tear down) media streams.
TCP is a horrible choice for media (RTP) packets; it's not clear from your writing if you're suggesting that.
Multicast is unlikely to work for many network paths/recipients.
routers play merry hell with incoming data; you'll need more than just SIP to deal with users on the open net. See STUN, TURN, ICE, UPnP, etc.
SIP or Session Initiation Protocol is a protocol that was designed specifically to address the problem you're trying to solve. Generally, the reason you should reuse (rather than reinvent the wheel) is because other people have studied the same problem and presumably have come up with a better solution as a collective group than you could as an individual. Of course that's not always true, but generally speaking it holds!
If you want to learn about SIP you could study the RFC 3261 specification, or start with the Wikipedia entry if you want a quick overview.
That being said, if you don't need the overhead of a complete and carefully tested protocol you could roll your own but make sure that when you're making that decision you know what you're foregoing and have a good reason to do so.
SIP is a signaling protocol that usually runs over TCP (although not required) and if you look at it closely you will see it is very similar to HTTP in many respects. Just like HTTP it can transport a great deal of payloads and it does so with text headers, much like HTTP can be used to transport HTML, XML, plain text or any arbitrary binary payload.
In the most simple system, you could just use Voice packets over RTP over UDP.
But you'd have no way to turn audio off, and would have to know IP addresses, port numbers, they type of codec and its characteristics beforehand.
In an overly simple view, SIP is a way to:
1. find the ip address of another endpoint from a URL. (May need STUN, TURN, ICE, etc)
2. agree on which codec to use and its options
There's a lot more to SIP than that, you may want to investigate SIP's conferencing features based on what you wrote.
You may write your own signaling protocol, and if this is for a school project, that will work just fine.
But if you are doing a commercial project, bear in mind that there is a lot more to telephony than meets the eye. The original SIP spec was greatly revised and is now a cluster of RFCs which are still being modified and added to. I recommend that you take advantage of this work rather than possibly reinventing the mistakes others have made.
I need some suggestion here. Do you think UDP is a better choice for sending the files from one pc to another or say from one device to another like iphone, android etc?
regards
Your question title says "video streaming", for which UDP is an appropriate choice. UDP does not guarantee packet delivery, but this doesn't really matter for video streaming.
The body of your question, however, says "sending files", which isn't exactly the same as streaming. If you're trying to transfer whole files from one device to another (and it's important that the entire file makes a successful transfer), then TCP is the way to go.
This is hard to intepret.
In the title, you talk about "streaming", but in the body you say "files".
Streaming is best done using UDP, since TCP always delivers data in order: if a packet is lost and must be re-send, the application won't get any data until TCP has solved it. For real-time data, this is undesirable.
Files are better sent using TCP.
Start to look at UDP when you wish to send to multiple recipients and the cost of throwing multiple boxes at the problem becomes excessive.
So assess the situation, the development cost of a UDP transport is higher to significantly higher than TCP and to some degree you are re-inventing TCP. The benefit of multicast is obvious, but what benefits are there for unicast? On modern hardware you have TCP acceleration which means UDP unicast is actually quite an expensive alternative. The arguments of lower latency are for specific applications, i.e. gaming, and more importantly are linked to lack of reliability and low capped data rates.
NB: The initial performance differential developers see between TCP and UDP is Nagle's and TCP slow start, i.e. congestion control, which is critical to scalability of inter-networks. Both can be disable for internal network applications.
Im going to develop one android application which transfer music file, contact exchange, voice chat, text chat etc.. through WiFi. Which protocol will suit my application UDP or TCP. Because both protocol having some merits and demerits. Can u give me some suggestion, it will helpful for me..
Thanks in advance
If you don't know which is better for your application, then you should use TCP. When you get to understand TCP and its limitations better, then you may want to delve into the arcane world of UDP.
If one was the best (universally), the other wouldn't exist anymore...
If you want to make sure, that the data you send is really delivered correct to the client: use TCP.
If you're application is performance critical and/or bandwith is a limiting factor and the data packages are small (fit in one frame), use UDP.
In your case, I'd use TCP/IP, because for streaming or big data it is necessary that all frames arrive in the correct sequence (or can be ordered by the client).
TCP.
UDP does not provide reliable transfer, which sounds essential for the applications you describe. For example, if you're exchanging contact details and half a phone number isn't received on the other end - which is very possible with UDP, how would you recover from that?
TCP:
This protocol is the most commonly used, the reason for this is its reliability on packet delivery, as each packet is guaranteed to arrive at its destination. its more commonly used for things like streaming media, where you do not wish to have data last/
With TCP, its slightly slower than UDP and has more features:
Ordered data transfer - the destination host rearranges according to sequence number
Retransmission of lost packets - any cumulative stream not acknowledged is retransmitted
Error-free data transfer (The checksum in UDP is optional)
Flow control - limits the rate a sender transfers data to guarantee reliable delivery. The Receiver continually hints the sender on how much data can be received (controlled by the sliding window). When the receiving host's buffer fills, the next acknowledgment contains a 0 in the window size, to stop transfer and allow the data in the buffer to be processed.
Congestion control
Source # Wikipeida > Transmission Control Protocol -> Data transfer
TCP would be the most best choice to start of with as its the most comment and has a wider range of features
You should use TCP, since you want to make sure your packets actually arrive.
TCP has a little processing and bandwidth overhead but makes sure your packets really do arrive and resends those which have not been reported to be arrived.
UDP is most commonly used in scenarios where the arrival of all packets is not mission critical, e.g. if you update movement data in an action game like a 1st person shooter. But even then, I'd use TCP these days.
The application you are talking about has a large spectrum of requirements in terms of networking. You might want to consider using:
TCP: for the delay tolerant needs e.g. non-realtime file/message transfer
UDP: for delay intolerant needs e.g. voice
With TCP, retransmission is built-in that which you don't get with UDP. You don't want to be retransmitting voice packets (as example).