Are the cell phone networks circuit- or packet-switched networks? Why?
I belive both of them but I'm not sure. I can't find an answer to my question on the net.
The short answer is both.
Traditionally, when a voice call is placed it goes over a circuit-switched network. However, in the last few years, VoLTE (Voice over LTE) has been rolling out, enabling voice calls to take place over a packet-switched network.
There is plenty of information about this on the web.
LTE ("4G") is a packet-switch only network for both data and voice. Older cellular networks (UMTS, HSDPA, HSUPA, GERAN) use circuit switch for voice calls.
Related
It is more or less asking how Whattsapp, Instagram, Facebook etc works.
How does my Phone know i got a new message even if the app is closed
(Please dont focus that much on the examples above, it is more a general question.)
I can think of a couple of solutions:
1.My Phone asks (in the background) an api every couple of seconds and fetches the data.
2.My Phone has an on going connection over the Web(i heard of technologies like: WebSocket, WebRTC, WebTransport, (standard) sockets, TCP)
My Phone is running a Webserver 24/7 and gets the signal like that
So in general the question is how can my PC/Phone etc. wait for a signal/data (Im talking 1, 2 or 3 bytes) in the background efficiently
it Highly Depends on the Operating System that the Program is Running on and also each OS has its own specific Security & Privacy Policy. However, all of them have a Common Agreement that this Types of Operation should be Handled in Background Processes as Secure Lightweight as Possible. so for your listed solution the closest one is 1th case.
2th Case almost Impossible because it is in Contradiction to being Lightweight
3th Case totally wrong way
I'm currently experiencing an intermittent issue with some VOIP WebRTC voice calls.
The symptom is that the outbound audio can sometimes fade in and out and sounds extremely muffled or even disappears momentarily. The 2 audio files reference here show examples or a snippet from a good call and then a bad call, both very close together. The audio is captured server side.
Good quality call - https://s3-eu-west-1.amazonaws.com/audio-samples-mlcl/Good.mp3
Poor quality call - https://s3-eu-west-1.amazonaws.com/audio-samples-mlcl/Poor.mp3
The tech stack is comprised of…
Electron application running on Mac/Windows
Electron wraps Chromium v66
WebRTC used within Chromium
OPUS codec used from client to server.
Wired network connection (stats show no packet loss and Jitter, RTT and delay are all very low)
SRTP used for media between client and TURN server (Coturn)
Cotur
Janus WebRTC Gateway
Freeswitch
These are using high-quality headsets and have been tested with various different manufacturers connecting to the Mac/Windows using USB.
Any ideas/help would be greatly be appreciated.
This might be a result of auto gain control. Try disabling it by passing autoGainControl: false to getUserMedia. In Chrome/electron googAutoGainControl and googAutoGainControl2 might still work.
I am attempting to stream audio files from a server to iOS devices and play them completely synchronized. For example on my phone I might be 20 secs into a song and then my friend next to me should also be 20 secs into the song as well. I know this is not an easy problem to solve, but I am attempting to do so.
I can currently get them within one second of each other by calculating the difference in time between the devices and then have them sync up, however that is not good enough because the human ear can detect a major difference in a second and this is over WIFI.
My next approach is going to be to unicast the one file from the server and then have the all devices pick it up directly from the server and then implement some type of buffer system similar to netflix so that network connectivity would be a limiting factor. http://www.wowza.com/ is what I would use to help with that.
I know this can be done, because http://lysn.in/ is does it with their app and I want to be able to do something similar.
Any other recommendations after I try my unicast option?
Would implementing firebase help solve a lot of the heavy lifting problems?
(1) In answer to ONE of your questions (the final one):
Firebase is not "realtime" in "that sense" -- PubNub is probably (almost certainly) the fastest "realtime" messaging for and between apps/browser/etc.
But they don't mean real-time in the sense of real-time, say, as race game engineers mean it or indeed in your use-case.
So firebase is not relevant to you here and won't help.
(2) Regarding your second general question: "how to synchronise time on two or more devices, given that we have communications delays."
Now, this is a really well-travelled problem in computer science.
It would be pointless outlining it here, because it is fully explained here http://www.ntp.org/ntpfaq/NTP-s-algo.htm if you click on "How is time synchronised"?
So in fact, to get a good time base on both machines, you should use that! Have both machines really accurately set a time to NTP using the existing (perfected for decades) NTP synchronisation.
(So for example https://stackoverflow.com/a/6744978/294884 )
In fact are you doing this?
It's possible that doing that will solve all your problems; then just agree to start at a certain exact time.
Hope it helps!
I would recommend against using the data movement to synchronize the playback. This should be straightforward to do with a buffer and a periodic "sync" signal that is sent at a period of < 1/2 the buffer size. Worst case this should generate a small blip on devices that get ahead or behind relative to the sync signal.
I would like to increase the loudness of the calls at the originating point. The mic on the set is no problem, but the earpiece or speaker at the originating end lacks acceptable volume. The volume thru windows is fine and adjustable, but does not allow communication volume adjustment. This problem is only apparent at the originating end.
Rob from Twilio here.
Thanks for the question on controlling volume of a call. Sounds from your description of "Windows" that you are accepting a call and answering with Twilio Client in a Windows-based browser - if I'm incorrect pleased let me know. There is no API control of the volume of a given participant in a call (full reference on modifying live calls here).
If the person calling into the Client user is having difficulty hearing, you may want to look at your microphone settings on your machine. Also make sure that you are using a headset and not your computer's built-in microphone. More tips on troubleshooting Client sound quality are available here.
This is a little off the beaten path. I've got a DLink DWL-G520 card I'm using under OpenBSD and it works fine. What I want to do is be able to access the radio part of it. Why? I want to use it in a radio telescope. It's a 2.4 GHz receiver with an external antenna connector. I want to connect some coax, some amplifiers, and an old TV dish and point the dish at the sky. It has an RSSI signal and variable RF gain (which it adjusts, from what I can find) so all I'd need to do is record those over time while pointed at a certain spot in the sky. I don't need to control the frequency really since most natural events are broadband.
I'm poking through the OpenBSD ath driver following nested structs but I don't want any of the normal network stuff, which is most of what the driver does. dmesg identifies it as an AR5212 which according to the Atheros PDF is always paired with an AR2112 radio. Is there any easier way than wading through PCI stuff to see what my options are? I need to turn the transmitter off so it doesn't fry my amps too. Trying to find low level documentation is about impossible from what I've seen. Ultimately I'd like to have this work with other WiFi cards too, but I'll start with this one. I've got a Cistron with an external antenna connector also.
Alan, ab1jx