Cablevision VoIP-Ready

I have Cablevision's Optimum Online service at home, and recently I've been having intermittent problems. After some adventures with their automated customer technical support application, I got through to a real live person, who said it was probably my old cable modem. Cablevision would replace it at no charge; all I had to do was go to their walk-in center and I could get a new one.

Interestingly, the new cable modem is a Motorola Surfboard SBV5120 with built-in ATA. [Correction: with eMTA, embedded Media Terminal Adapter; thanks to "VoIP Dude" for the clarification.] I don't subscribe to Optimum Voice (Cablevision's VoIP service). But when talking with another CTS rep later in the day, he mentioned that they're giving out cable modems with eMTAs (though he didn't call them that) to all their customers, so if the customer later decides to buy Optimum Voice, they don't need a cable modem swap.

This tells me a couple things. First, the price differential between the SBV5120 and the SB5100 has to be pretty small. Second, Cablevision has to be expecting a pretty reasonable take rate for Optimum Voice among current Optimum Online customers.

VoIP and 911

I think I lose my Telecom Blogger Card if I don't write something about the FCC's VoIP E911 order. So some observations.

First, basing any conclusions on the FCC's press release, instead of the Report and Order that isn't available yet, is risky. The language is imprecise, the requirements are fuzzy, and the obligations are unclear.

That said...

The FCC's determination of who it's placing obligations on seems broad. "Interconnected VoIP service providers," that have obligations placed on them, are defined as those who "enable customers to receive calls from and terminate calls to the public switched telephone network." By that definition, Skype (for example) could be considered an "Interconnected VoIP service provider", as Skype (the company that offers the SkypeIn and SkypeOut services) enables customers to receive calls from and terminate calls to the public switched telephone network. The definition of "Interconnected VoIP service providers" says nothing about how the provider markets the service, or whether there's an ATA supporting 2500 sets - all it says is "enable customers to receive calls from and terminate calls to the public switched telephone network."

The consistent use of the term "interconnected VoIP provider" to describe who the FCC is placing obligations on, but a change to the term "telecommunications carrier" to describe who the ILECs are obligated to provide E911 access to, is worrisome. While I suspect that the overwhelming majority of VoIP providers make use of a CLEC or a third-party provider such as Intrado to provide E911 interconnection, this apparent limitation of the obligations of the ILECs to their current "statutory obligation to provide requesting telecommunications carriers access to their 911 network" makes Chairman Martin's statement that "VoIP providers may interconnect directly with the incumbent LECs’ 911 network or purchase access to this network from competitive carriers and other third-party providers" sound somewhat disingenuous.

Finally, the Commission doesn't seem to have thought through the implications of "nomadic VoIP" - taking one's ATA (or using one's softphone or IP phone) somewhere other than the "subscribed address".

The first conclusion the Commission reached is that "Interconnected VoIP providers must deliver all 911 calls to the customer's local emergency operator."

The second conclusion the Commission reached is that "Interconnected VoIP providers must provide emergency call operators with the ... location information of their customers... Although the customer most provide the location information, the VoIP provider must provide the customer a means of updating this information, whether he or she is at home or away from home." (Emphasis mine.)

For a VoIP provider to deliver 911 calls to a customer's local emergency operator, they have to have E911 trunks to the selective router (tandem switch) serving the PSAP responsible for the local area in which the customer is located. Some carriers (AT&T, SunRocket, AOL) have indicated they may have to limit the availability of their VoIP services to areas in which they are currently able to offer E911 (i.e., areas where they have E911 trunks to the ILEC tandem).

Fine. But what about when someone takes their Vonage WiFi phone to their vacation house in Wisconsin, where Vonage doesn't have E911? Even if Vonage gives them the ability to update their location information - even if Vonage had the ability to figure out their location information autonomously, the holy grail of VoIP E911 - Vonage can't deliver that customer's 911 calls to their local emergency operator, because they don't have the trunks into the local 911 tandem.

Basically, a requirement to deliver all 911 calls to the correct PSAP for nomadic customers is a requirement for every VoIP operator to establish trunking (either directly or through a third party) into the 911 tandem serving every one of the 6200 PSAPs in the country.

Personally, I think it would be amusing to see each of the 400 VoIP providers in North America send a few thousand Access Service Requests to the ILECs, for E911 trunking into every single 911 tandem in the US. We'd see how well the ILECs could service a million ASRs in the next 120 days.

On the other hand, I'd note that Intrado's stock went up 13.44% on Thursday.

Holes in the Lawn

OK, my last eight posts have been about Skype, so I've got to find something else to talk about.

As I mowed the lawn over the weekend, I realized I have a lot of holes in my lawn. There are the patches that get squashed where number one son and I stand to play catch. There's the spot under the swingset where number two son drags the toes of his sneakers when he's on the swings. There are the patches where the flowerpots go as bases for the kickball games.

I'm glad I have holes in my lawn.

Skype Bits and Bytes

Lars writes rather dismissively about the bandwidth requirements for Skype over a wireless data connection, quoting and attempting to correct an article titled "Why Skype for Mobile isn't a Big Deal" in an online publication called The Feature, which is owned by Nokia.

First, the quote from The Feature:

Skype says its software uses 0-0.5 KBps when idle, or 3-16 KBps when on a call. That's 30 KB per minute when idle or beween 180 and 960 KB per minute on a call -- which on many mobile networks would run up a huge bill quite quickly.

Then, Lars's attempt at countering the math:

To use the author's own words, there is a bit of a disconnect in his calculations between bandwidth (measured in kbps) and storage (measured in KB) and consequently between his deductions and reality. Multiplying the kbps by 60 does NOT lead to a KB value per minute (as the author has done). There are 1.000 bits in a kilobit (10^3 bits) and 1.024 bytes in a kilobyte (2^10 bytes), while one byte consists of 8 bits. So to convert from a bit-value to a byte-value you need to divide the bit-value by 8. Hence, 1.000 bits are 125 bytes. So by using the author's figures, a bandwidth rate of 16 kbps for Skype would actually mean transfering 2.000 bytes per second or 120.000 bytes per minute or exactly 117,1875 KB per minute - a far cry from the 960 KB per minute claimed.

The only problem is, the author of the article in The Feature was directly citing Skype's figures, which are stated in kilobytes per second:

How much bandwidth does Skype use when there are no active calls?

On average Skype uses 0-0.5 kilobytes/sec while idle. This is used mainly for contact presence updates. The exact bandwidth depends on many factors.

How much bandwidth does Skype use while I'm in a call?

Skype automatically selects the best codec depending on the connection between yourself and the person you are calling. On average, Skype uses between 3-16 kilobytes/sec depending on bandwidth available for other party, network conditions in between, callers CPU performance, etc.

So doing the math myself - Skype uses up to 4 kilobits per second (kb/s) while idle, and anywhere between 24 and 128kb/s for an active call. And the original author's math is exactly correct: an idle Skype client will use as much as 30 kilobytes per minute, and a Skype call will consume anywhere from 180 to 960 kilobytes per minute.

Also note that generally-accepted practice is to use the ISO abbreviation "k" for kilo = 10^3, and the character "K", which does not stand for anything, for 2^10. Thus, a kilobit is 1000 bits, a kilobyte is 1000 bytes, and a Kbyte - usually shortened to simply a KB or K - is 1024 bytes.

So a one-minute Skype call will result in data transfer of between 175K and 937K. Using the Vodafone D2 rates Lars quotes, 0.0963 cents (Euro) per KB, that'll cost you between 17 and 90 cents (Euro) per minute. (For those of you in the US, the cheapest Verizon Wireless plan seems to be 60MB for $59.99, or 0.0977 cents US per KB, so that Skype call would cost between 17 and 92 cents US per minute.)

Why Skype chooses to cite bandwidth figures in kilobytes per second instead of the more common kilobits per second is left as an exercise to the paranoid.

SkypeOut and SkypeIn Gateways, Yet Again

I think I can milk this topic for one more post.

Looking again at James Enck's item on the Skype architecture, I realize I inferred "media gateways" where I read "gateways". That's not necessarily the correct interpretation. "Gateways" could mean IP-IP gateways, performing a Session Border Controller-type role. This would be the point at which the internal Skype protocol, whatever it is, is decrypted and translated to the version of SIP required by the particular carrier partner, and the media stream is decrypted (as well as little details like counting minutes are taken care of).

This makes more sense to me than Skype converting IP to TDM to handoff to their carrier partners. Still not as disruptive as simply building these capabilities into the client software and letting it run on an arbitrary supernode, but I guess sometimes architectural purity can take a backseat to pragmatism.

Skype and SIP

In a comment on a previous post, muppetmaster pointed to an ongoing discussion in the Skype Forum. In it, a Skype staffer says directly that "skype client does not implement/use SIP". Apparently a field in the shared.xml Skype config file is named , leading some to believe (as did my interpretation of Skype error codes) that SIP was implemented in the client.

Of course, it's possible that the Skype developers simply borrowed SIP terminology in developing their own protocol. (Developers like to borrow things.) It's also possible that the Skype proprietary protocol is 99.999% SIP. (As I said, developers like to borrow things.) And except to the protocol zealots, it doesn't really matter either way. The Skype protocol is unpublished and its transmission is encrypted, so unless Skype decides they want to allow arbitrary SIP clients to interwork with Skype, it's not going to happen.

And as long as Skype has a larger user base than the SIP world, they're not going to want it to happen. (For a detailed examination of why this is the case, see this paper, quoted below:)

...if network value scales like n log(n), as we argue ... then relative gains from interconnection depend on the sizes of the networks. In this case the smaller network gains considerably more than the larger one. This produces an incentive for larger networks to refuse to interconnect without payment...

Skype Supernodes

James Enck, commenting on the ongoing banter between myself and Aswath on SkypeOut and SkypeIn gateways, notes that he has "long assumed that Skype has 'seeded' a number of its own supernodes globally from day one." The Baset and Schulzrinne Skype Protocol Analysis observed what they called "bootstrap supernodes" - seven IP addresses and port pairs that always showed up in the Skype Host Cache on the initial installation of the Skype Client. It's very reasonable to think that these bootstrap supernodes are run by Skype, supporting James's assumption.

SkypeOut and SkypeIn Gateways, Part 3

James Enck reports that Skype "has built and deployed its own-spec gateways," and Aswath is puzzled. As am I, but then, I'm a natural-born skeptic. Aswath's puzzlement is centered on (1) why use G.729a for SkypeOut calls instead of the GIPS iSAC codec if they're your own gateways, and (2) do the calls get handed off to the carrier partner as TDM and then converted back to VoIP?

More conjectures: Media gateways need hardware. I don't see Skype buying DSPs and building boards from scratch; seems more likely they'd be buying the hardware from someone like AudioCodes or Brooktrout. This hardware doesn't support the GIPS iSAC codec. GIPS offers a version of its VoiceEngine(TM) product for embedded devices, which could conceivably be embedded in a third-party media gateway card - but this version doesn't support the iSAC codec. So I can see Skype's inability to use iSAC for SkypeOut/SkypeIn calls. And if you're unable to use the GIPS codecs, then G.729a isn't an unreasonable choice if you want Skype to work reasonably well over low-bandwidth connections (since G.711 is a bandwidth hog, as I noted previously).

If Skype is indeed converting G.729a VoIP to G.711 TDM to handoff to its carrier partners, and the carrier partners are carrying the traffic as VoIP across their networks (pick a codec) and converting back to G.711 TDM to handoff to the PSTN, that would do more to explain the recurring complaints about SkypeOut sound quality. The more codecs you string together, the worse the sound gets.

If James's info is correct, Skype starts looking less and less disruptive and more and more like a telco. (And not only a telco, but a vertically-integrated telco.) And it's not clear to me that being a telco is something Skype is very good at - or even something they should want to be good at.

SkypeOut and SkypeIn Gateways, Part 2

Aswath provides an alternative conjecture on how Skype clients signal to Skype's carrier partners' media gateways. The two main differences between our theories (if I'm interpreting him correctly) are (1) he thinks that Skype is running dedicated servers as supernodes for SkypeIn and SkypeOut calls, where my theory is that they're using "any old supernode"; (2) he thinks the clients are talking the internal Skype protocol to supernodes, which translate to SIP, where my theory is that the clients are talking SIP with a supernode acting as a SIP proxy.

Given the dearth of actual data this is all built upon, it's hard to argue either conjecture. But there are some differing implications depending on which way it may work.

If Skype is in fact running dedicated servers as supernodes for SkypeIn and SkypeOut, growth in these services will require investment on Skype's part to meet the capacity demand. Given that Skype is collecting revenue for these services - and the revenue is prepaid - that's not a killer; however, it makes the business model less compelling. If they're using "any old supernode", growth is cheaper since they're making use of arbitrary users' computing resources.
Aswath's point about dedicated servers providing a few well-known interconnection points is a good one, though.

The other distinction, whether Skype clients are running "native SIP" with a supernode SIP proxy server, or whether a supernode translates for "Skype-ese" to SIP, I think is more of academic interest.

SkypeOut and SkypeIn Gateways

I've been thinking about SkypeOut and SkypeIn.

For Skype-to-Skype calls, Skype, as has been documented, uses a proprietary call signaling protocol and the GIPS iSAC and iLBC codecs. It is also reported that Skype uses G.729a for SkypeOut calls. I'm assuming the same holds for SkypeIn calls

Skype shows Colt, Level3, iBasis, Teleglobe, Cable & Wireless, and B3G as "Carrier Partners", implying that these are the companies that provide the interfaces to the PSTN.

Somewhere, SkypeOut traffic has to be converted from G.729a packets to G.711 A-law or mu-law TDM (and the reverse for SkypeIn). And somewhere, call control signaling has to be converted to some standard PSTN signaling for network interconnection.

A couple of questions come to mind:

1. What are the media gateways that convert G.729a VoIP to G.711 TDM, and who owns and runs them?

2. How do the Skype clients communicate with the media gateways?

Now, I have no real information on this topic and have done no experimentation to try to figure this out (it'd be interesting to see Salman Baset and Henning Schulzrinne revisit their Skype Analysis cited above for SkypeIn/SkypeOut). However, some detective work and reasoning can lead to some interesting conjectures. Bear in mind that these are just that - conjectures. Differing views are welcomed...

First conjecture: Skype uses direct IP handoff to their carrier partners; the carrier partners do the TDM conversion.

Reasoning: first, several of Skype's Carrier Partners offer VoIP services with direct IP handoff to the carrier network (e.g., iBasis DirectVoIP, Teleglobe VoIPLink, Level3 (3)Voice Termination). Second, Skype's architecture has an almost congenital avoidance of centralized servers under Skype's control. "Apart from the login server, there is no central server inthe Skype network." [Baset and Schulzrinne] And given Skype's model, I'd find it surprising if they invested in any hardware when they could avoid it.

Second conjecture: SkypeOut call control signaling is SIP from the Skype Client through a supernode serving as a SIP proxy and then to the carrier partner's media gateway.

Reasoning: The carriers cited above provide IP handoff using either H.323 or SIP. SIP is a text-based protocol that would be relatively easy to work with for developers familiar with internet methods; H.323 is a binary protocol defined using ASN.1 that wouldn't. SkypeOut error codes (10403, 10404, 10408, 10484, 10487, 10500, 10503) map directly to and have the same meaning as corresponding SIP Response Codes. Skype uses supernodes to assist with functions like firewall traversal and dealing with NAT, so it seems logical they'd use it for SIP proxying as well - and it seems to me counter to the peer-to-peer model to have supernodes translating from Skype's proprietary protocol to SIP. Though the SIP proxy has to be smart enough to know not to encrypt the messages going to the carrier partner's media gateway.

Alternately, Skype could be using dedicated SIP proxy servers instead of supernodes. That would, however, cause them to incur more capital cost for SkypeOut. Which also seems unlikely.

Not conjectured upon at this time: How does the Skype supernode "find" the appropriate partner's media gateway for a given PSTN number?

Serial Codecs

In a comment on Tom Evslin's post on SkypeOut, Edward Vielmetti notes "some really bad artifacts calling out from SkypeOut through the PSTN into someone else's VOIP phone, enough to make the call too poor quality to carry on a business conversation."

Skype uses the Global IP Sound iSAC codec for Skype-to-Skype calls, but uses G.729a for SkypeOut calls. Most VoIP providers use G.711.

Various reports (sorry, no links I can find) indicate G.729a gives a Mean Opinion Score (MOS) in the range of 3.75 to 4.0, which is perfectly acceptable. G.711 MOS is generally between 4.1 and 4.5. However, serial coding (G.729a to G.711) generally drops the MOS between 0.5 and 0.75 points.

Not knowing details about Skype's implementation of the G.729a codec or the circuit gateway they're using, it's hard to say more.