In response to my previous post on FCC ruling on E911 service, Frank Muto suggested that use of ATA and standard phone could be the deciding factor in determining whether a service is interconnected or not. Martin Geddes also suggests that for consumers this is a simple test. A little analysis will suggest that this classification scheme doesn’t resolve the issue.
I am of the understanding that players like Free World Dialup are exempt from this ruling because they do not offer interconnection to PSTN. But they do allow the use of ATAs. So FWD needs to offer E911 service? That will be interesting, especially given the fact that they have been previously granted exemption from regulation.
Use of PC can not be a guide as well, because then we have to define PC.I suppose a fair definition could be PC is something that has a processor, OS, input and output devices. Doesn’t ATA+2500 set a PC then? After all it also has a processor and an OS; the mike and keypad are the input devices and the speaker is the output device. There are reports that Skype will embed their software in home routers, thereby making the router to be an ATA. At that time, does Skype have to offer E911 service?
Presence of RJ-45 (or is it RJ-11?, asks DG Lewis; it doesn’t matter) is not that reliable a measure either. There are some devices that have integrated the ATA functions and a cordless phone. They do not have a RJ-11 jack and have only a RJ-45 jack. Does that mean an integrated device exempt from this ruling?
I don’t think using the form factor of the user device gives us a good solution.
Added: After posting this entry, I noticed that Om also feels Duck test is appropriate.
I learnt through Om (subsequently Andy and Skype Journal) that Skype has started a blog. Naturally, I visited that site and was pleasantly surprised to see my name under We read. I am sure they read more than the short list they have posted. I take it as a high complement, especially given what I have written about them so far. This is in contrast to the other company that comes out swinging at me as if I am a piñata. For the record, my interest continues to be network architecture and user interfaces and not any company’s business success or failure.
By the way the entry regarding (in)stability of phone system in Japan brings up the old debate about proper network operation during disaster periods. PSTN uses the “focused overload” procedure and allows traffic only from restricted parties, because PSTN has only binary control. Internet on the other hand allows all traffic to flow at the risk of reducing the performance for everyone. This debate comes up periodically. We should not discuss which one is better. Fortunately for us we have both the networks and as users we should benefit from both, exploiting the inherent advantages in each one of them.
Last week FCC issued an order requiring E911 service from interconnected VoIP providers. Just as I have done, I am sure that by this time you also would have read many news items and blog entries discussing this ruling. But I am a bit confused about the specific definition of the term. Since we do not have access to the full ruling, we have to go by the explanatory remark made in the press release. The point of this entry is to suggest that a VoIP service provider, who is otherwise not interconnected, can become interconnected by actions taken by external third parties and so the commission will be required to provide additional explanation.
The press release says that interconnected VoIP providers “are similar to traditional telephone providers in that they enable customers to receive calls from and terminate calls to the public switched telephone network (PSTN).” It goes on to say that “it does not place obligations on other IP-based service providers, such as those that provide instant messaging or Internet Gaming
Services, because although these services may contain a voice component, customers of these
Services cannot receive calls from and place calls to the PSTN.” Well and good.
As a practical matter, E911 service will require interconnection to PSTN, both In and Out. The PSAPs will not be ready to accept native IP traffic within 120 days. So Out service is required if users have to call E911 service. Since the emergency operators must be able to call back, the users must subscribe to In service as well. So bundling of both In and Out is a requirement.
But there is a problem with this definition. Any service provider can become an interconnected VoIP provider by the actions of an external third party. For example, users of both AOL IM and Yahoo IM can make calls to PSTN through Net2Phone. Given the revenue potential of terminating calls from PSTN, somebody can decide to offer to terminate calls from PSTN on behalf of users of these two IM services, with or without their explicit concurrence. In this case, are AOL IM and Yahoo IM interconnected VoIP providers? If FCC clarifies their definition to protect against this, then any service provider who does not want to offer E911 access, just have to unbundle the In and Out services. So in the final analysis, the recent FCC ruling is directed to the incumbents that they have to provide access to E911 network for any willing VoIP service provider who offers both In and Out services. FCC is not going to require a VoIP provider to offer access to E911; they have given even allowance for anyone to claim an exemption. It is the market that may demand this.
Russell Shaw recently wrote about a list of features that people have requested of Vonage. The specific list of features is not that important; instead what is remarkable are two other things: first that users are asking a service provider, second, that the service provider is slow in meeting these demands.
We have been told for so long that the intelligence has moved to the end. If that is so, then why are the users asking the service providers for new features? Shouldn’t they be asking the end-device manufacturers? Oh wait. I forgot that the devices have been sufficiently lobotomized that any feature however basic can be realized only with the help of the service provider.
The other thing we are told often is that one of the biggest benefits of SIP is that features can be developed in a jiffy (the often repeated phrase in the halls of the building that once housed bellheads was that in the new world “features can be developed in the garage by the undergraduates”). What is more, the features can be deployed in a distributed manner. But still most of the requests remain unfulfilled. Is there anyway to blame the bellheads for this state of affairs?
Shouldn’t our reaction be something similar to the anchorman in the movie Network?
Immediately after deploying Skype, its CEO defended their decision to use a proprietary system rather than use the SIP standard. He was widely quoted as having dismissed the SIP option to be inferior. This has sprung up in Skype Forum. Muppetmaster informs us that one of the Skype configurable parameters is labeled SipServers and an item under it is called DirectlyConnected. He goes on to suggest that this is evidence that Skype client runs SIP when it wants to interconnect to PSTN. A few days back DGLewis raised this same point. In that context I commented that there are operational benefits in Skype client following the same procedure independent of whether the call terminates at PSTN or not. This entry does not revisit that issue, but explores why Skype may not be satisfied with SIP and concludes that SIP can easily accommodate these requirements.
A communications protocol needs to identify the end-points involved in the session, specify the mode and format of the communication and finally identify any network resources it may want to use during the session. All protocols do these in one form or another. Q.931 of ISDN and H.323 are competent in this respect, contradicting the widely held belief. SIP does these as well. So what are missing from SIP (or for that matter H.323) that Skype would need. I can think of two things.
The first one is these protocols use UDP to transport the media packets, but many firewalls block UDP traffic. In these cases, unlike the standard protocols, Skype uses TCP in these cases. This is counter to the established security policies and hence it is not advisable that standard protocols be extended to use this scheme.
The second one involves NAT traversal. The standard scheme is to use Session Border Controllers and use UDP Hole Punching for optimization purposes. The two standard protocols use one set of port(s) to carry the signaling information and other port(s) to carry media. Because of this, the optimization scheme does not work if even one of the end-points is behind an asymmetric NAT. On the other hand, if the media port can receive limited signaling information then we can devise a method by which the optimization procedure will work as long as both the end points are not behind asymmetric NATs. Interestingly, according to Baset and Schulzrinne, Skype does not use this scheme.
So it is not clear what Skype achieves by using a non-standard signaling protocol.
There have been (idle?) speculations on Skype’s PSTN interconnect architecture. It was first started by DG Lewis and then by me that prompted Lewis to post an update. Now James Enck joins the table with a possible insider information. I will say that it is pretty explosive!
No Virginia. Skype is not free of network infrastructure. They have built and deployed their own media gateways. Normally I would have rejected it outright. But Enck is saying this and that too he is quoting company sources. So I am really puzzled. First of all, if they have deployed their own gateways, then why use G.729 codec for SkypeOut calls; why not use the usual codec which is the rave of the industry? Secondly how does it work? Is the handoff traffic to their carier partners in TDM format, which they then convert it back to VoIP? This is some thing to ponder.
Enck also says that he had assumed for a long time that Skype has deployed their own supernodes. I am glad to hear that. But he is not forthcoming about relay nodes. But there will be an occasion to state that as well. For a long time Vonage and its apologists were claiming that they do not have any network infrastructure and are still able to offer voice service. It has stopped as the network failures became well known. Slowly it is becoming Skype’s turn. Pulver used to talk about Heteromorphic Communications. I wonder whether there is a term for a mammal turning into a dinosaur. If Mr. Powell is reading this, I would like to ask him whether he still thinks that “the game is over”.
Feeling smug and smart. Hence the tone of this post.
A few days back I commented that people seem to be careless when they use Skype statistics. Here is a recent example. That story tells us that Skype claims that they have 2 million subscribers worldwide. I thought it is something like 35 million and they have 2 million concurrent users online at any given time. No matter; it gets more interesting. The story goes on to tell us that Vonage does not consider Skype to be a competitor. According to the article, Skype retorts by saying that “over half its subscribers now use [SkypeOut]”. Mix and match the numbers; quote incorrectly; do whatever it takes to build a story the way you want it to be. This is journalism?
My entry about SIP, Skype and The Bull created different interpretation than I intended. But a comment posted by VelvetFog in this thread suggests that there is another calf wanting to be the Bull. According to this,
I say that all protocols are almost equivalent. So can we stop this bickering and focus on enriching the user interface and user experience?
DG Lewis shares his thoughts on Skype PSTN interconnect architecture. He argues that Skype probably uses the media gateways of its carrier partners, instead of deploying their own. He also theorizes that they do not use any specialized signaling gateways as well. Instead he thinks that the Skype clients use SIP signaling for SkypeOut calls. He is left with one open question – how does a supernode know which carrier partner to use for a given call. What follows are my thoughts.
Originally I wrote this as a comment at Lewis' site. Since it become longer, I decided to make an entry. That explains why it is written in second person.
I agree with you that Skype has not deployed their own media gateways. Then they have to worry about getting physical connectivity to their partners. Why taken on operational burden when (as you point out) the partners accept IP traffic.
But I have different thoughts on the signaling aspects. My theory is that they treat the media gateways as Skype clients and so they "register" with a supernode, which are Skype's own computers. These supernodes map Skype protocol to SIP. Here SIP is only a "trunking" protocol. So the mapping is not complex. This model covers many other requirements:
This violates the P2P nature and this is your basis for suggesting the alternative. But I am of the opinion that Skype has deployed relay nodes to handle NAT traversal problem. So deploying additional supernodes is not an additional burden.
But then again I am biased in that I think in the final analysis there is architectural difference between Skype and other VoIP service providers.
It has become routine that lots of imprecisely defines statistics are used while discussing Skype. Invariably the imprecision is used favorably and is used till it is outed. So it was the number of downloads; but now almost nobody bothers to mention it, even though that banner still adorns Skype website. It has been replaced by a few others that are not so easily seen to be irrelevant: number of concurrent users, number of Skype minutes served and number of SkypeOut subscribers.
It is not clear how Skype counts the number of minutes serverd (which stands at 8.3 billion). People have theorized that Skype aggregates usage report from individual clients; some others think that this statistics is collected from the supernodes. But the question remains as to what steps Skype takes to ensure double counting does not take place. With this background, it is all the more interesting that estimates are being made on Skype’s revenue potential. For example, this article in News Factor Technology News claims that “[a]t an average of, say, five cents per minute, that’s $380 million in revenue Skype just sucked into the ether.” (We have to assume that the counter stood at 7.6 billion when this article was written.) Now we know based on some bloggers confession that it is routine for people to leave the Skype connection on even though neither end is actively conversing. How do we assume that these 7.6 billion communication minutes would have been used on the PSTN network had Skype not come along?
The next up is the number of SkypeOut users. This could be the number of SkypeOut transactions or the number of unique users who have bought ShypeOut credits. Obviously, the latter is better than the former. Given that ambiguously defined metrics have been used earlier suggests that we have to clarify before we use it to estimate the revenue potential.
A couple of days back Qwest posted on their website information on their VoIP offering OneFlex. Indeed it is so quite that they have not announced press release and my usual sources like Om, Andy and Jeff have not discussed it. But their offering is interesting in some ways while it is an “yet another voip service”.
OneFlex is an ATA based service. They ship the device as part of the enrollment. The device has a fail-over to PSTN port. The service has the standard list of features like Caller ID, call waiting 3-way calling and of course the marvel of them all, “virtual number”. This is the garden variety part.
The interesting part is the tariff. To begin with the monthly charge $30 plus $3 for long distance. Besides being in the high range, it does NOT include long distance. Long distance charge is about 5 cents a minute, with a cap of $20 (the $3 is included in the cap). It is interesting because it is a compromise between all you can eat scheme and a strict usage charge scheme. (To hijack a recently introduced term) Skypeage?
Today I stumbled upon a thread referenced at del.icio.us, where one of the posters states that he has developed a Perl script to display Caller ID information on the TV screen, by accessing the SIP messages directly and using MythTV.
This suggests a general solution: connect the modem line from the PC to the SIP ATA, along with the standard phone; let a PC application “sniff” SIP signaling information that the ATA is receiving and transmitting to the service provider. For those who remember TAPI or TSAPI, I am just replacing PSTN with SIP. The level of commonality between the service providers in their use of SIP will determine how ubiquitous an application can be across the service providers. This brings us to the recent discussion on the lack of SIP API.