Comp 346/488: Intro to Telecommunications
Tuesdays and Thursdays, 6:00-9:15, Lewis
Class 11: Aug 4
Optional reading (Stallings 7th -- 9th editions)
Chapters 3, 4 and 5
CDMA: chapter 9 (partly available on Sakai), Chapter 14
ATM: chapter 11, 13.5 & 13.6
You may bring one page (one side) of
your own notes.
Flowroute: I finally met up with them at ClueCon, down the street! Here are
a few things I learned:
- Flowroute is in Seattle! Even though every Flowroute server I've ever
connected to geolocates to Nevada.
- They know about the setting-up-accounts-for-class problem, and they're
still working on it. The guy I talked to, who I'd never met before, had
heard of my issue.
- They're still working on SMS support. The problem, oddly, is outbound:
supposedly they already have an experimental API for allowing the
inbound forwarding of SMS messages. When it's implemented, that means
you can use your Flowroute DID (number) as a stand-in for your cell
phone; it will be able to accept and forward both calls and texts.
- The conference they were attending (and sponsoring) is about
FreeSwitch, a competitor to Asterisk (FreeSwitch started out as a clean
rewrite of Asterisk). There are good things about FreeSwitch, but their
dialplan language is XML, and, bad as Asterisk's is, the FreeSwitch
language is probably harder.
- I first heard about Flowroute in a talk at the 2600 conference The
Last Hope, by Kevin Mitnick; you can find it at T=~25:00 at youtube.com/watch?v=oWj4mvSvpgs.
Mitnick's demo used Flowroute to unmask CallerID-blocking. In the talk,
Mitnick points out that if a caller from the PSTN tries to block their
CallerID, Flowroute removes the CallerID information from the SIP setup
packets, and sets the privacy-requested flag. However, they also
would forward the unedited P-Asserted-Identity string, serving to
identify the caller. A few years ago I contacted Flowroute tech support
and they weren't really familiar with Mitnick but did tell me they
didn't forward P-Asserted-Identity except for "reseller" accounts; that
is, to other phone companies (Mitnick may have legitimately set up such
an account). Today I found out that Mitnick's exploit is quite
well known at Flowroute, but that Flowroute stopped exporting
P-Asserted-Identity (when CallerID is blocked) to anybody,
some years ago. (You can still get a personal 800 number, though.)
- Flowroute is vaguely concerned about CallerID spoofing (that is, you
setting up a phone that appears to be someone else). However, legally
it's not their problem. They do keep logs, though, to trace back any
problem call to the account holder. In Illinois, CallerID spoofing is
illegal only if it is done with the intent to mislead.
- Some of the Flowroute employees can't wait for IPv6
support, to put an end to NAT troubles; recall that setting up the RTP
data path to a phone behind a NAT firewall is complicated. IPv6 will
allow all phones to have publicly accessible IPv6 addresses. But the
problem isn't at Flowroute; it's at the PSTN connection sites. They
have to upgrade to IPv6 before we get anywhere.
- In some of the packet traces we've looked at of Flowroute calls, I've
commented that the other end of the RTP connection does not appear to be
very conveniently located in terms of minimizing the physical distance
that the PSTN portion of the call has to travel. For example, in networks.html
we looked at a call placed from my office Asterisk/Flowroute phone to my
office PSTN phone; the call was routed via Texas. Each voice packet from
the Asterisk/Flowroute phone traveled over the Internet to Texas, and
then back over the PSTN to Chicago. That apparent inefficiency, however,
turns out to be unimportant: what is important is that
Flowroute connects the call to the IP interface of the destination provider.
If I'm calling an AT&T number, for example, then Flowroute sets up
the RTP data path to AT&T's IP interface, wherever it happens to be,
and the PSTN path is then entirely internal to AT&T. They don't care
about the length. The only thing that costs money is carrier-to-carrier
exchanges. The Texas end of this call was owned by Excel Communications,
who may have been accepting the call under contract.
- Some ISPs do honor Differentiated Services (DS)
flags in the packet header. Ask yours, the next time your ISP's account
manager takes you to lunch! (Hint: large customers only.) Getting your
DS flags honored as your packets cross over into the next ISP
is even less certain.
Why RTP doesn't send RTCP (ACK) packets
WebRTC and Google Voice
Bucket (we did all of section 18.9)
Fair Queuing (short)
Tuning a link for VoIP capacity