Comp 346/488: Intro to Telecommunications

• An Overview of Networks
• Virtual circuits
• ATM
• wireless
• Wi-Fi
• Wi-Fi polling mode
• WiMAX and LTE
• Token bucket
• Fair Queuing
• Integrated Services and RSVP
• Differentiated Services
• MPLS

1. Flowroute is in Seattle! Even though every Flowroute server I've ever connected to geolocates to Nevada.
   
   
2. 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.
   
   
3. 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.
   
   
4. 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.
   
   
5. 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.)
   
   
6. 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.
   
   
7. 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.
   
   
8. 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.
   
   
9. 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.