What is the difference between Cellular calls and VoIP calls in LTE. As both use IP packets to send data to EPC. Without internet VoIP calls doesn't work but cellular calls work. Am I missing something?
VoLTE calls are the true operator calls, made directly on the phone dialer and whose audio packets go through your carrier's 4G IMS network. VoLTE calls are a type of VoIP call (such as VoLTE, VoWifi, VoNR). They use a dedicated EPS bearer that has controlled quality of service determined by your carrier. If your operator or your phone doesn't support VoLTE/IMS, your phone will fallback to 2G/3G to complete the call. This is not a VoIP call, but a CS (circuit-switched) call -- as 2G/3G are not PS (packet-switched) networks.
So the "cellular calls" in LTE are also VoIP calls -- they're just not OTT (over-the-top) VoIP calls.
These OTT VoIP calls (WhatsApp/Skype/Zoom calls) are calls made by applications that can only use the default internet bearer, so they don't have guaranteed quality of service for that data bearer. Packet delay (latency), packet loss, priority and bitrate parameters are completely different for that bearer.
These OTT VoIP calls lack very important features such as CS fallback, call continuity (SRVCC), supplementary services and most importantly emergency services (911).
A VoIP call will be treated as internet traffic, that is best effort internet traffic. It will travel over the air, to the EPC and then on to the public internet. The mobile operator will handle it as any other internet traffic. The mobile operator will not do any call handling.
A 'cellular' call will be treated by the mobile operator as true VoIP. It will have associated quality of service (focus on latency). It will be handled by the operator call control platform. If going to another network it will be sent over a private IP network, again guaranteeing quality of service.
Now, in practice, the best effort public internet might just be more than good enough.
Related
first of all: What i am trying to do is only for private interest.
I'd like to connect a AT-09/HM-10 BLE-Module with Firmware 6.01 to another device which provides also a BLE Module, which it is not based on the CC254X-Chip,
I am able to communicate with this Device using my Laptop with integrated Bluetooth, Linux and the bluepy-helper. I am also able to make a connection using the HM10 through a USB-RS232-Module and "Hterm", but after that quite Stuck in my progress.
By "reverse-engineering" the Android-Application for controlling this particular device i found a set of Commands, stored as Strings in Hex-Format. The Java-Application itself sends out the particular Command combined with a CRC16-Modbus-Value in addition with a Request (whatever it is), to a particular Service and Characteristic UUID.
I also have a Wireshark-Protocol pulled from my Android-Phone while the application was connected to the particular device, but i am unable to find the commands extracted from the .apk in this protocol.
This is where i get stuck. After making a connection and sending out the Command+CRC16-Value i get no response at all, so i am thinking that my intentions are wrong. I am also not quite sure how the HM-10-Firmware handles / maps the Service and Char-UUIDs from the destination device.
Are there probably any special AT-Commands which would fit my need?
I am absolutely not into the technical depths of Bluetooth and its communication layer at all. The only thing i know is that the HM-10 connects to a selected BLE-Device and after that it provides a Serial I/O and data flows between the endpoints.
I have no clue how and if it can handle Data flow to certain Service/Char UUIDs from the destination endpoint, althrough it seems to have built-in the GATT , l2cap-Services and so on. Surely it handles all the neccessary communication by itself, but i don´t know where i get access to the "front-end" at all.
Best regards !
I set up my own asterisk voip server and i was able to make calls to my extension but how do i get it so I would have an actual phone number people from the outside can call in. lets say i want the phone number
555-1234 and if someone calls that number it gets routed to my voip server then i process it and etc..
I was presuming that this would work similarly like DNS where you go buy a number and then point it to your server with an A record. Then from there nginx processes the server request and provides appropriate web pages and so on.
Some information on this would be fantastic as I have no idea where to go for this kind of stuff and google hits isnt revealing a lot.
You need to get a DID (Direct Inward Dialing) from a VoIP provider. There are many ITSP providers up there that can provide DID and then send it to your Asterisk server (called SIP Trunking) and from there you can configure Asterisk to terminate the call on specific extension or IVR.
Also, DIDs are usually provided by tier 1 carrier (companies like Bell Canada, AT&T, Verizon etc). Again, DID (Direct Inward Dialing) is not something you can simply advertise from your Asterisk server unless of course you want to allow people to call you by IP. For example, 5551234#YourAsteriskIP will make sure extension ring. But users from a non sip devices (ie landline) cannot call your number.
this is my first question here and I realize this question might be open ended, but I'm looking for specific solutions, and any solution would be accepted.
I have GPS devices which send data packets to an IP on a port, both of which I can configure. I wish to use one of Google's, Amazon's or Microsoft's offering of cloud services. I am using python. Here is an implementation I found online :-
https://github.com/rdkls/gps-tracker-server
The data is coming as packets which are not over HTTP protocol. I have considered building a network listener over a socket on Google Compute Engine, but I'm not sure if it will be able to handle simultaneous requests from 1000 devices if such a situation ever arises. The Google Cloud IoT core offering seems to fit my need perfectly, but it is in private beta right now, which means I can't use it. I think I'll need a message queue service. But most of the offerings from these three companies requires messages over HTTP. Keep in mind that I can't change how the messages are sent from the GPS devices.
The messages sent are in this format -
https://drive.google.com/file/d/0B2EklrIn3KugS2NJYWZGWlVWeGdMbjM4WHQ2TUZmYWhIRmt3/view?usp=drive_web
Format:
data is sent in (byte sized) packets directly to the IP:Port over GPRS connections, one heartbeat packet every minute and GPS details every minute from each device. It also requires teh server to eply to the messagee for acknowledgement since it's not over TCP/IP.
So basically, which service and which architecture should I use keeping scalability, reliability and cost in mind?
I think for a 1000 devices, that would send such messages every minute, total would be 43M messages. I'm not sure but I'm looking for something that'll cost me about 1000$ that is 1$ per device per month.
I understand many of the fine details of NAT hole punching, ICE, and SIP VOIP calls. I've answered quite a few questions on SO on these topics. Now I have a question.
I am trying to understand the need for the RE-INVITE message that is documented for SIP+ICE after the call is already established.
Assume a topology of VOIP devices that signal over SIP and using ICE (with STUN/TURN) for establishing media connectivity. After the ICE connectivity checks are performed, both endpoints should have ascertained the best address candidate pairings (IP,port) and should be ready to stream media in both directions.
But my experience with SIP and plenty of documentation suggests that after the callee sends a 200 OK message to indicate he's in the answered state, the caller is to expected send a RE-INVITE with an SDP containing the specific address candidate selected by the connectivity checks.
Some links that describe the RE-INVITE with ICE are here and here (step 8). Rosenberg's tutorial (page 30) discusses that the RE-INVITE "ensures that middleboxes have the correct media address". I'm not sure why that's important.
Upon receiving a RE-INVITE, is the callee expected to reconfigure his ICE stack to switch sockets or addresses based on the new SDP received? Or is the RE-INVITE just a protocol formality to formally acknowledge the call has been established? If the RE-INVITE step was skipped and both sides started streaming media, what could go wrong?
The reason why I ask is because I am exploring using ICE over a signaling service that is not SIP. I'm trying to figure out if the RE-INVITE needs to be emulated.
One example of middlebox, which may be interested in the result of the ICE negotiation is a bandwidth manager.
Imagine an enterprise deployment, with endpoints inside the corporate firewall and others roaming around on the Internet, or behind private home firewalls. The deployment also includes a publicly accessible TURN server. Then let's imagine an endpoint inside the corporate firewall making a call. If the destination happens to be reachable on the same network, the call will go host to host and the TURN server will not be used (i.e. bindings will be de-allocated). This is a local network, and no bandwidth limitation needs to be imposed. On the other hand, if the call goes out to a roaming endpoint, then the TURN server will get involved, and data will flow through the corporate firewall, through what probably is a limited bandwidth uplink. We can very well imagine some policy that would want to limit the call's bandwidth. One way of doing it, is for the bandwidth manager to remain in the signaling path (using SIP record-routes) and look into the SDP of any INVITE going through, re-writing bandwidth values depending on media addresses.
I believe the general intention was, that legacy equipment of that type, which is not ICE aware, should keep working in a mixed environment introducing ICE endpoints. To keep this backwards compatibility, ICE should only introduce new processing (STUN checks, etc), but from the point of view of non-ICE-aware elements, it should not remove any existing rules (re-INVITEs are still needed to change the destination of a media stream).
In Rosenberg's tutorial I believe the re-INVITE is sent because the sockets chosen by ICE are different from those in the media and connection (m/c-lines) lines of the original SDP AND in order for any network elements that are in between the two user agents to be informed of the actual sockets that will be used RTP a re-INVITE is sent with the ICE selected socket(s) in the media and connection lines of the SDP.
If the ICE selected sockets were the same as the ones in the original INVITE request's SDP m/c lines then there would be no need for the re-INVITE request. Or if you know there are no "middleboxes" that need to be informed of the changes to the RTP sockets then there would also be no need to send the re-INVITE.
I am supposed to develop a USSD gateway for an operator so please help me with the following
-can I use asterisk for this purpose?
-can the asterisk system take alphanumeric characters as user input.
USSD is transported via SS7.
In order to build a USSD gateway you either need a SS7 protocol stack supporting the MAP protocol or a separate SS7 gateway (e.g. MAP-to-SOAP converter) for accessing the SS7 network. This is typically something you purchase from someone who knows what he does.
While it may be possible to (ab)use Asterisk for message routing, I would expect that you get faster results with some message gateway framework or by building an application on your own. Depends on what business logic you actually want to build on top of USSD.