Telephony

There are 28 posts filed in Telephony (this is page 1 of 3).

Verizon Wireless is killing me

I’m stuck in Verizon bureaucratic hell.

When I moved to the United States in August, the iPhone 4 was nearing the end of its product lifecycle.  I wasn’t about to spend $400 for a device that was going to be replaced by what we thought was the iPhone 5 (but turned out to be the 4S). Instead, I decided to get the cheapest device I could get until the new iPhone was released: a Verizon Wireless prepaid phone. I obtained a hand-me-down device, and activated it with a new number.

When the iPhone 4S was finally released in October, I went to the store and plunked down my money for a pre-order (a stupid term if I ever heard one, by the way; “pre-order” is the state I was in before I ordered the phone). Naturally, due to my special circumstances as a) a customer switching from a prepaid to a contract plan, and b) my Canadian citizenship, I caused our local Verizon store representative no end of trouble. Moreover, he couldn’t migrate my prepaid number to the new iPhone because it hadn’t arrived yet – it was out of stock for weeks. So he assigned me a dummy phone number and told me I could migrate the number once the device arrived. Continue reading →

Could Usage-Based Billing work?

In my last post, I talked about why Internet usage-based-billing (UBB) is detrimental to both content producers and consumers. But my friend Davison raised an excellent question: could UBB work if the price was right?

After some deliberation, I would have to say yes, with some caveats. The argument in favour of UBB is about fairness: those who use more bandwidth should have to pay for it. Most rational people would agree that this method of billing has its merits. After all, that’s how we’re billed for electricity and gas; why shouldn’t it be the same for bandwidth? And don’t corporations pay for bandwidth this way already? Continue reading →

A content producer’s take on Usage-Based Billing

The Canadian Radio and Telecommunications Commission recently issued a decision on usage-based billing and I’d like to comment from the perspective of a large-scale, Internet video supplier. (Insert the usual disclaimer about my opinions not representing my employer’s.)

As many readers know, I work for the Canadian Broadcasting Corporation in digital media operations. It’s extremely important for our customers — the Canadian taxpayer — to have cheap, unmetered bandwidth, so that they can watch our programming online. “Online” means not only the content that users can stream directly from our website using the CBC player, but also the content we send to our channel partners: iTunes, NetFlix, YouTube, and so on.

The adoption of usage-based billing across the board will drastically affect our ability to reach consumers over the Internet. It doesn’t take very long to go through 25 gigabytes of streaming data in a month. For Bell and other incumbent carriers to characterize anyone who uses over 25 GB/mo as a “bandwidth hog” grossly misstates the available capacity on the Internet today. Otherwise, why should it be possible for a commercial entity to purchase unlimited bandwidth ADSL service from Bell using essentially the same technology as home DSL, but without being metered?

I could continue, but let me instead quote some folks who have said it better than I could: Netflix. Here’s an interesting excerpt from Netflix’s investor relations website; specifically, their Q4 Letter To Shareholders (PDF). Obviously, I’m not speaking for CBC when I say this, but I think the comments here fairly represent the challenges that we, as an “Internet video supplier”, face under a usage-based billing regime.

Delivering Internet video in scale creates costs for both Netflix and for ISPs. We think the cost sharing between Internet video suppliers and ISPs should be that we have to haul the bits to the various regional front-doors that the ISPs operate, and that they then carry the bits the last mile to the consumer who has requested them, with each side paying its own costs. This open, regional, no-charges, interchange model is something for which we are advocating. Today, some ISPs charge us, or our CDN partners, to let in the bits their customers have requested from us, and we think this is inappropriate. As long as we pay for getting the bits to the regional interchanges of the ISP’s choosing, we don’t think they should be able to use their exclusive control of their residential customers to force us to pay them to let in the data their customers’ desire. Their customers already pay them to deliver the bits on their network, and requiring us to pay even though we deliver the bits to their network is an inappropriate reflection of their last mile exclusive control of their residential customers. Conversely, this open, regional, no-charges model should disallow content providers like Netflix and ESPN3 from shutting off certain ISPs unless those ISPs pay the content provider. Hopefully, we can get broad voluntary agreement on this open, regional, no-charges, interchange model. Some ISPs already operate by this open, regional, no-charges, interchange model, but without any commitment to maintain it going forward.

and

An independent negative issue for Netflix and other Internet video providers would be a move by wired ISPs to shift consumers to pay-per-gigabyte models instead of the current unlimited-up-to-a-large-cap approach. We hope this doesn’t happen, and will do what we can to promote the unlimited-up-to-a-large-cap model. Wired ISPs have large fixed costs of building and maintaining their last mile network of residential cable and fiber. The ISPs’ costs, however, to deliver a marginal gigabyte, which is about an hour of viewing, from one of our regional interchange points over their last mile wired network to the consumer is less than a penny, and falling, so there is no reason that pay-per-gigabyte is economically necessary. Moreover, at $1 per gigabyte over wired networks, it would be grossly overpriced.

I’ll close by giving you a sense of how outrageous a $1/GB charge is.

CBC pays pennies per gigabyte to our CDN to deliver content to the ISP’s front door. Some portion of that is the CDN’s profit, and yet they are still able to meet the marginal cost obligations of expanding their network. In fact, by using a CDN, we are paying a premium to the actual cost of the delivery of the bits, for the benefit of leveraging the CDN’s robust infrastructure, ability to scale, and many points of presence.

From an network engineering perspective, there really is no difference between a CDN and an ISP; in fact, the CDN transfers far more data per year across a far more complex worldwide data network. If our CDN can do it for such a low cost, why can’t Bell? I can only arrive at the same conclusion as Netflix: that Bell and other incumbent “last mile” providers are using their monopolistic ownership of those connections to justify outlandish charges to the customer.

faxing over IP networks: there must be a better way!

Faxing over IP networks does not work reliably. There are many technical reasons why; I won’t go into them here. This page provides a pretty detailed explanation about why trying to transmit analog modem signals over an IP network will not work — variable jitter, insufficient bandwidth, silence suppression and many other factors in VoIP call handling will work together to destroy your faxes. There are two main solutions in the FoIP (Fax over IP) space:

  • T.37 (store-and-forward): Use e-mail as the IP transport medium. T.37 defines a protocol by which faxes are converted to an e-mail message and then delivered to a T.37 endpoint – whether that is someone’s email box, or a device capable of translating the attachment into a fax image and then sending it to the target fax machine using the PSTN.
  • T.38 (real-time fax): Use either “Internet-capable” (T.38) fax machines, analog telephone adapters, or a combination of T.38 aware/compatible devices to transmit faxes using special UDP packets.

Neither of these mechanisms is particularly elegant. In fact, the adoption rate of T.38 is quite low among ATA makers, and many implementations are buggy. Also, the fact that T.38 must be implemented on both ends of a call is another nail in the coffin.

Let’s step back a moment here and reconsider what we want to do. Suppose I am a business owner considering (or having switched) to a VoIP network, but I still have my old (non-T.38 capable) fax machine. I want to send faxes to any other fax device in the world, and I don’t care whether the receiver’s equipment is T.38 capable or not. I am willing to invest in a T.38 ATA, and assume that I can do so without too much cost or effort, and that it will work reasonably well. What do I do? Continue reading →

DECT and SIP

I haven’t had much of a chance to write about technology issues recently; quite frankly, not a lot has been happening that has interested me. Sure, Apple has announced a new MacBook that’s really thin, but, as usual, it has the 100% Apple markup over anything sensible. I mean, $3,000 for a notebook? I know that $1,000 of that is probably to pay for the solid-state drive, but I’m not even convinced that such technology is really necessary. I contrast this to a $500 Acer Eee laptop that would more than meet my needs! (Too bad the name is retarded, kind of like the Nintendo Wii)

Enough about Steve Jobs’ latest money printing scheme; I want to talk about telephony again. I went to a TAUG meeting tonight on the topic of integrating DECT with SIP. DECT is one of those technologies that has been around for a generation but has largely been ignored in North America; only recently has there been any uptake. Most people (myself included, at least up until about 4 hours ago) don’t even know that cordless phone systems that you can buy at Best Buy use DECT – okay, the example I linked to is a bit unfair since it says “DECT 6.0” right in the headline, but you get the idea. My friend Brian had a set of these in 2005 but I wasn’t any the wiser that it wasn’t just a regular WDCT set on the 2.4 GHz spectrum.

Continue reading →

Nokia N800 Internet Tablet and WPA2-PSK

A few weeks ago, my friend Brian lent me his Nokia N800 Internet Tablet, because he has gone and purchased an Apple iPhone and no longer needs it. I was hoping to try and use it as a SIP client on my VoIP network, so that I could wander about the house and still make calls. (Unfortunately, the N800 isn’t actually a phone, which makes it somewhat limited in functionality.) For the life of me, though, I can’t get the damn thing to talk WPA2! Continue reading →

hacking the Samsung a920 mobile phone

I spent part of the weekend hacking my company-issued Samsung a920 cell phone. I guess “hacking” is a bit of a strong term – my sole objective was to get certain MIDP applications installed on it. I have a nameless-but-trustworthy-source inside Bell Mobility that confirms they block the download of MIDP apps that it doesn’t like, for example, MidpSSH or Opera Mini. Presumably, they do this by parsing the JAD file and rejecting source domains in the MIDlet-Jar-URLthat aren’t in a whitelist.

Fortunately, this thread on HowardForums gives you the lowdown on how to break into the a920 firmware to forcibly load MIDP applications on there. I had to really screw around with UniCDMA (i.e. randomly selecting different phone models) before it would spit out my SPC, but eventually I got it. The instructions on using Qualcomm’s EFS Explorer worked like a charm.

I have to admire the phone developers for their humour in naming various directories on the phone’s filesystem. The root is called "brew", presumably because the phone is Java-capable. The _policy.txt file that you can overwrite in order to remove some of the restrictions on the phone lives in a directory called "obione". (I didn’t touch the _policy.txt because I accomplished my goal just by writing the apps to the phone’s filesystem, which is good enough for me.)

Anyway, I now have Opera Mini and MidpSSH running nicely on the phone! (Nicely, I guess, if you consider that typing SSH commands using T9 is pretty painful.)

back online with dry DSL

Meredith & I moved into a house at the beginning of April and for our Internet connectivity, I retained my EGate DSL service — only on a dry local loop, i.e. without dial tone. This is commonly known as Naked DSL, and this means I no longer have to pay Bell Canada a minimum of $25.00 per month for telephone service that I don’t really need. Now mind you, EGate still has to pay BellNexxia a $12 fee monthly for providing the dry loop, so that gets added onto my DSL bill. Continue reading →