This is an app (there are both free and pro versions) available only for
Android. The developer site is kaibits-software.com.
It provides information on your cellular and LTE network: signal strength,
cell (station/system/network), MNC/MCC, etc. Right now, for example, it
shows my cell as
station ID 34497
system ID 4384
network id 122
My MCC (Mobile Country Code) is 311, and my MNC (Mobile Network Code) is
580. We can look these up at wikipedia.org/wiki/Mobile_country_code
to find this is US Cellular.
(Do this example after the networks Overview chapter.)
The issue isn't reducing queuing delays, but rather reducing
inefficient-routing delays.
Two phones cannot talk together directly. My phone is at 166.232.**.**. It
lies behind a NAT router, with address 166.181.3.216 which turns out to be a
site in Pennsylvania owned by Wireless Data
Service Provider Corp (we can check the location with www.ip2location.com
or www.ipligence.com).
This is my NAT front end.
The upshot of this is that, whenever I connect to the Internet using my data
plan, my traffic travels through Pennsylvania. From Pennsylvania to me,
routing is via a private network.
This also means that my phone cannot accept data-plan incoming connections
at all; all it can do is initiate outbound connections. If Snapchat or
Facebook or TextSecure wants to be able to send a message to me,they
can only do so if my phone has first reached out to them. Which it has: my
phone has dozens of TCP connections open to outside sites, for just this
purpose.
If Alice calls Bob using RedPhone, Alice connects to one of WhisperSystems'
data centers and asks where Bob is. The trick is to find the data center
nearest to Alice, so that the path through the Internet is reasonably close
to minimal. Within the US this doesn't matter much, but it does in other
parts of the world. WhisperSystems chose a two-step plan, first using DNS
and then multiple TCP connections. The plan is based on a small number of
DNS servers worldwide, and a rather larger number of switching servers. The
switching servers are also more dispersed geographically.
Step 1: Alice's RedPhone uses DNS to find the
WhisperSystems DNS server nearest to it (see map). Different DNS servers in
different parts of the world resolve the same name to different (local) IP
addresses. This is a good start, but note the issue if Alice and Bob are
both in South Africa.
The DNS server returns a list of multiple switching
servers, each with a different address.
Step 2: Alice's phone takes the list of switching servers,
and attempts to connect to all of them, in parallel. The first one that
answers is the one Alice's phone uses; the other connections are immediately
closed. Alice's phone could also ping each of these servers, but that is an
additional RTT.
All VoIP solutions contend with packet
switched networks that were not designed to transmit real-time media
streams. Packet latency and packet loss are the principal manifestations
of this reality, and the jitter
buffer is their canonical solution.
They then describe an adaptive-jitter-buffer algorithm, where the buffer can
change size. That's a bit of a trick, as that means slowing down or speeding
up the audio.