Comp 346/488: Intro to Telecommunications

Tuesdays and Thursdays, 6:00-9:15, Lewis Towers 410

Class 2
AICN readings:
    An Overview of Networks
   
   
Optional reading (Stallings 7th -- 9th editions)
10.1, 10.2, 10.3
Chapter 1: 1.3, 1.4
Chapter 2, 2.1-2.6, especially 2.3 on TCP/IP


Network Signal Info

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.



WhisperSystems, RedPhone and Creating a Low-Latency Calling Network

(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.

The next blog post by Whisper Systems, on Client-Side Audio Quality, goes on to say

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.



Notes: