June 20, 2005

Cup is Half Empty

An updated statistics is now available from Skype (ignore the linear growth; assume no intermediate data has been plotted) and the usual round of wow is going around. Even Om is welling up and it is safe to predict that his heart will be fluttering with the release of the next round of statistics.

First a summary of the statistics that we are told so far:
Registered number of users: 35M to 40M
Concurrent users online at any time: 2M to 3M
Number of Skype minutes in a month day: 40M to 50M minutes

A decidedly trouble maker’s interpretation of these numbers:

  1. Less than 10% of users are online at any given time, thereby reducing the “network effect” tremendously. But wait. This is good, because this means users need voice mail, a subscription service.
  2. So a user is generating an average of less than 2 minutes per month day. Alternatively, most of the users are using Skype for text chat (because they are searching for the headset, generalizing from personal experience).

Phil is very conservative in his predictions. A Skypist (as opposed to a Skype user, known as Skyper) should hope to see at least 80% users online at any given time. Of course, the number of minutes served must be aleph-0, not any finite number (since google is spoken for).

Posted by aswath at 06:19 PM | Comments (0)

June 18, 2005

Why not we Speex more often?

During early 80s, the bellheads were trying to use wideband codec for voice communication. Those feeble attempts failed along with its benefactor ISDN. Now with the widespread deployment of VoIP, it is more likely use of wideband codec will be routine. But early deployments didn’t use them, because they were more focused on replicating/replacing POTS phone service. Thanks to Skype, more people are aware of the benefits of wideband codec and are exploring incorporating these codecs in their offerings. Two well known examples of this class of codecs are iSAC from Global IP Sound and G.722.2, an ITU standard that will be used in 3G deployments. Both have licensing or patent restrictions. As I was researching this topic, I came across an open and free codec called Speex. This has both narrowband and wideband components and requires comparable bandwidth. From the google search it looks like the quality is quite good. Xten, Asterisk and Open323 (did you now that they also support SIP) all support this codec. I hope that Speex is used more widely by other VoIP service providers. Since Speex is royalty free, media gateway vendors must be able to upgrade their products to support this codec.

The only hitch is I am not sure whether ATA users will observe the added benefit of using a wideband codec.

Posted by aswath at 12:20 PM | Comments (3)

June 12, 2005

Skyped Claims

It is universally accepted that Skype is virally marketed with very little expenditure. But savvy claims that go unchallenged also plays a role in establishing the aura of genius. A recent interview (via Skype Journal) given by Niklas Zennström, CEO of Skype to EE Times is but the latest example of this.

EE Times wondered how Skype can offer better voice quality compare to other VoIP service providers and PSTN even. The answer is noteworthy. Here is a snippet:

“Skype is the only one that uses peer-to-peer technology for voice services. Other VoIP services are using a client-server technology… It can take advantage of full broadband bandwidth, so you don't need to compress the voice as much to get a richer sound experience.

First, it is erroneous to state that Skype does not use client-server technology; most assuredly it uses client-server architecture. If the supernodes are not servers, what are they?

Second, let us assume that for the sake of argument, that Skype is peer-to-peer. But the question is about voice quality. So what matters is the flow of media packets. By now it is well known (by Skype’s own admission) it uses UDP hole punching algorithm, just as many Session Border Controllers used by other providers. So the media flow will be directly between the end-points in either case. If there is indeed a difference in voice quality, the only explanation must be the codec.

But from the response to the question, “Have you invented your own codec for this?” we learn that they use “industry-standard codecs like G.729 and G.711, iLBC and iSAC.” We are told that these are only some of the codecs they use. Probably there are some secret ones that give them a leg up. Otherwise can’t others use these same industry-standard codecs and remove any possible differences in voice quality? I recall in one of the very early news items on Skype, it was claimed (see note below) that a team of audio experts had worked in addressing the voice quality problem and have come up with a better solution. Probably they have come up with a proprietary codec. (You own a bridge as well?)

The second statement that is worth noting is this one: “It [peer-to-peer] takes the shortest route between end users.” By implication, this is applicable to Skype as well. But another very early story (see note below) suggested that Skype finds multiple routes between the two end-points and picks one route that gives the best voice quality. It was further implied, that when the voice quality deteriorates an alternate route will be picked. So which one is true - Skype doing routing at a higher layer or the routing is done by the IP layer independent of Skype?

The third interesting statement is what we learn about the amount of compression Skype does. We are told that, “A normal telephone signal in the digital telephone network is compressed to 56 kilobits per second, which is pretty much the same as the modem line. But we can pretty much take advantage of the broadband network and use a richer sound that doesn't have to be compressed as much.” Really? The folklore says that Skype uses primarily iSAC codec from Global IP Sound. The datasheet on iSAC states that the maximum transmission rate is only 32 kbps. Looks like a lot of compression to me, given that it is a wideband codec with a higher sampling rate. (I will not take a cheap shot and point out that the uplink speed in modem tops out at 33.6 kbps.)

It sure looks like part of the viral marketing is to create an aura of mystery and a notion of uniqueness.

Note: I am not able to give reference to the two news stories, even though I have read them. I will appreciate it if you know the references and provide them to me.

Posted by aswath at 07:11 PM | Comments (7)

June 10, 2005

An Overlooked E911 Requirement?

Recently FCC issued a ruling on E911, requiring qualified VoIP providers to comply with the ruling within 120 days. All the discussions in the media and blogs have focused on location determination and how to accurately report that information to the emergency operator. If I remember correctly there are other requirements that have received scant attention, of which one may be difficult to implement within the required period.

There are three requirements related to “premature” call clearing initiated by the caller:

  1. If, during the exchange of information the caller does not respond, the operator must be able to generate a high pitched tone (I forget the technical term for this tone).
  2. If the caller disconnects the call abruptly, the operator must be able to call back the caller.
  3. If the caller hangs up the phone but picks up the phone within 45 minutes, then the caller must be reconnected to the same operator as long as the operator has not disconnected.

It is straight forward to see that the first two requirements are easily met. But VoIP clients require additional intelligence to meet the third requirement:

  1. The client should recognize that an emergency call has been initiated.
  2. The client should not initiate call clearing procedure on its own, but wait for the operator to initiate it.
  3. If the user requests clearing anyway, the client should store the session ID (or equivalent) till the operator clears the call or for 45 minutes, whichever comes first.
  4. During this period, if the user wants to initiate a session, then the client should not follow the standard session setup procedure (dial-tone, digit collection etc) but directly issue reInvite (or equivalent) using the stored session ID.

This means that the ATAs deployed in the field need to be upgraded to meet this particular E911 requirement. So the question is whether this has to be done within the stipulated deadline? Or we will collectively ignore it because this covers an unlikely event?

Posted by aswath at 03:07 AM | Comments (2)

June 06, 2005

Location Update with POTS Phone

DGLewis has posted an entry (first in what promises to be a series on FCC’s recent E911 ruling) reviewing FCC requirement that states that "at least one option that requires use only of the CPE necessary to access the interconnected VoIP service." He feels that one way to meet this requirement is to employ the services of customer service department. Given the sorry state of responsiveness of these departments, he goes on to suggest that this scheme will not meet another requirement that requires timely notification. But I think technology is on hand to meet this requirement.

DGLewis indicates, as everybody will also suggest that web technology be used to update the location information. The interesting thing is that we could use VXML, another web technology to accommodate the sticky scenario as well. But we have to pay attention so that the data entry is simplified. How about the following suggestion?

Data entry steps:

  1. Enter the zip code
  2. Enter the digits corresponding to the first n letters of the street name, followed by #
  3. The system utters matching street name(s) one by one - # to select it and * to move to the next in the list
  4. Enter the door number
  5. Enter the Apt/Suite number if needed
  6. System utters the full address and gets confirmed

If you have any doubt, just ask Tellme or somebody like that.

Posted by aswath at 11:01 PM | Comments (3)

June 01, 2005

Skype Parasites

Andy comments about Zoom’s Pay as you go service. (By the way they seem to offer an In service as well.) Recently Russell Shaw compared Vonage and Skype and suggests that for certain usage models Pay as you go scheme will be more economical. But it is not clear which model is preferable for a service provider.

Subscription model gives predictable, monthly revenue; but enrolling subscriber might be a costly proposition as is evident from points discussed by Om in many of his recent postings. On the other hand, Pay as you go scheme has no holding power. More importantly, in IP networks, it is easy for competitors to parasitically offer services. For example there is a company called Connectotel that offers SMS connectivity to subscribers of Skype. They have released a document on how this is done. By following the instructions in that document, one can offer clones of SkypeIn and SkypeOut services, For example, I could find a rate that is cheaper to call India (using PSTN) than what SkypeOut offers. So I could selectively use this competitor’s service, if they offer it via Skype. Since they do not have to provide local POPs in PSTN, their operating cost should be less. This is why I am surprised that these companies that offer international calling cards have not flocked to VoIP subscribers.

Posted by aswath at 04:20 PM | Comments (0)

Copyright © 2003-2009 Moca Educational Products.