February 25, 2007

Development Issues in IMS

If you are involved in developing applications in the IMS environment, Brough Turner gave a webinar on this topic last week. You will find it very useful. Personally, I wish he had touched on two points:

  1. Feature interaction issues and its impact. In the webinar, he draws strong connection to IN. Given that and the known issues of feature interaction that affected the growth of services in IN, it would have been to nice to hear his views on this topic as it relates to IMS.
  2. With Apple’s iPhone leading the charge, it is likely that soon, the handset will determine the user interface. So developing new features will require close cooperation with handset manufacturers before new features can be introduced in IMS. I wish to know of his views on this as it affects one of the prime objectives of IMS – ease of introduction of new features.

Posted by aswath at 07:54 PM | Comments (0)

Verizon Flaunts It ... Modestly

Recently Verizon has decided that it should flaunt what it has. In their judgement, what they have got is … High Quality Network. They have started to advertise in local TV proclaiming this with their “It’s On” ad campaign. These ads claim that their network is always on and gives “99.99% reliability”. Now you have heard even from many ardent VoIP promoters will grant that PSTN has “5 nines” reliability. So I wonder why Verizon is short changing itself? Is it because the intended competitors offer less reliability? Is the number conservative because voice service in FiOS depends on local power and not network power? I have questions, but no answers.

Posted by aswath at 07:53 PM | Comments (1)

February 13, 2007

PSTN vs. VoIP - Kettle and Pot

This morning Andy linked to a USA Today story. According to that story, “consumers finally get a grip on VoIP”. Of course the story doesn’t produce much convincing evidence. But in the process it gives us some choice quotations. The first one is the claim by the reporter: “VoIP and traditional phone service both offer voice calls, but that's where the similarity stops: Owing to its Internet-based format, VoIP allows a circus of other features, including Internet access and e-mail.” (By the way, I am not petty to take issue with an obvious editorial error – VoIP does not “allow” internet access and e-mail.) So I was eager to see some of these features. After all “If VoIP is just a replacement item (for traditional phone service) that sits on your counter, it's not that compelling." This is not according to me but Phil Asmundson, vice chairman and a U.S. managing partner, technology for Deloitte & Touche. So the story quotes Tom Rutledge, chief operating officer of Cablevision, “One of cable's biggest VoIP success stories”. According to him, ability to check voice mail on the Web, program home phones with different rings for different callers and monitor call histories are some the prominent features. So who is going to point out that these are not unique to VoIP and that PSTN can do these just as well. Not Verizon. According to the Verizon spokesman Eric Rabe these features are common with voice over IP services, including "Voice Wing," which is Verizon's VoIP product. On second thought, he adds that “Verizon can provide many of the same services on the traditional phone.” He is so modest, he refuses to name that service. One wonders.

The fact is that we don’t need VoIP service providers and for that matter Verizon’s special PSTN service. If you need these features on PSTN, get PhoneGnome box (look for "Plug and Play box", for $60), hook it up (a very simple process) and get all these services for free. Yes, they offer VoIP service; but you can totally ignore that and still can get all these features. All for free, with no recurring charges. It really roils me whenever I read that VoIP can do something that PSTN can not. Here is a provocative thought – PSTN is also IP. Since IP allows for any technology on the “sub-network”, why can’t PSTN be considered a “sub-network”?

Posted by aswath at 08:17 PM | Comments (0)

February 11, 2007

VoIP Hardware Need Note Be Boring

A couple of days back Phoneboy bemoaned the fact that he does not excited with VoIP hardware because there has not been much innovation taking place. He also told us that the last cool thing he saw was SPA-3000. Apparently one can do nifty things once “you understand how it works and, furthermore, how to configure it.” In a related post, Andy points out that this once again confirms his thesis that poor marketing is the main reason. I would like to add that there is another reason – not being true to the technology.

In my opinion, the promise of VoIP was/is that:

  1. the end users can signal to each other directly, without any intermediaries;
  2. multi-modal communication and picking the appropriate mode facilitated by the direct signaling connection;
  3. adjust the mode of communication in reaction to the changing network connection and/or the nature of communication.

To my knowledge, no VoIP hardware has even tried to deliver on these promises. To a large extent, the hardware manufacturers have focused on aping the PSTN service model by slightly modifying the architecture. They have catered to VoIP service providers, by miniaturizing the traditional Class 5 switch (calling it ATA, a dreaded term from the ISDN era). Otherwise nothing has changed. Added to this, the VoIP service providers, in their quest to increase the ARPU, have preferred to keep the cost of ATA at a low level. Of course, an implication of this is the ATAs are boring devices. This is the reason that I am not in full agreement with Luca’s analysis that VoIP has been successful, let alone the reasons.

There was a time when people have claimed that VoIP is a product and not a service. But we have not been true to the technology. Instead, the whole industry has worked on developing a service. Once we return to the real promises of this technology, VoIP hardware will become exciting.

Posted by aswath at 07:03 PM | Comments (4)

February 02, 2007

Competitive VoIP CAN Strike Back

In a recent post, Om Malik points out that competitive VoIP providers like Vonage and Sunrocket will face difficult times in light of cable operators’ increasing market share and the bundled offers from AT&T and Verizon. But there is a way for competitive VoIP providers to fight back. The inspiration should come from mobile industry, which introduces increasingly sophisticated handset. Analogously, instead of giving away limited and staid ATA’s, they could push different devices like screen based phones. They shouldn’t stop there; given such devises, they could offer features and services that take advantage of them. It is still not too late. If the note lacks details, then you know how to get it from me. Of course, MSOs can follow suit, but that is bound to happen if “arms dealer” is involved.

Posted by aswath at 08:48 PM | Comments (0)

Another Anti-Phishing Scheme for OpenID

Just as OpenID is getting traction, there has been increasing “chatter” that it could be prone to phishing attacks. OpenID wiki has a section that describes the scenario and also lists different recommended actions OpenID Providers (OP), users and the clients can take to mitigate the problem. The purpose of this note is to suggest an alternate login ceremony that can totally eliminate the risk of a phishing attack. The new scheme does not affect existing implementations at the OP and the Relaying Party (RP).

The new proposal requires that a button be added to the browser toolbar that will facilitate the verification procedure. The user will click that button when it is required to generate and provide ID credential to a RP (as it is shown in the accompanying screenshot).

OP Toolbar Button

This will trigger the following sequence of events:

  1. The tool will collect the URL of the current page and will ask the user to enter the OpenID.
  2. The tool will determine the OP using the standard mechanism and will generate a checked_setup/checked_immediate message. Of course this message will not contain the parameter openid.assoc_handle.
  3. If the OP needs to interact with the user, then it will be done on a new window.
  4. Once the authentication procedure is completed, the new window will be closed; the OP will generate a response to checked_* message and the client will send it to the RP from the original window.
  5. Among other things, the response will contain the user’s OpenID and the token. The RP can use the standard authentication procedure by sending a check_authentication request to OP.

Observations:

  1. RP is not involved in redirecting the user to the OP, which is mildly disorienting for new users. Any interaction between the user and the OP is totally isolated from the RP. Hence there is no phishing opportunity for a rogue RP.
  2. There is no change to the procedural logic at the OP and the impact to RP is minimal.
  3. The proposed scheme does not utilize the Association procedure and consequently may increase the load at the OP. But the use of nonce to minimize the replay attacks suggests that the benefits of using the Association procedure is lost in the base scheme itself.

Posted by aswath at 06:49 PM | Comments (1)

Still Looking for Voice 2.0 Features

There was a time when Jeff Pulver will periodically lament about lack of new and exciting features and will talk about Purple minutes that became Purple Applications. A few days back, David Beckemeyer raised the same concern. He points out that even though he has deployed many “Class 5 switches” via PhoneGnome with easy to use API that can be used to offer new and exciting services, only a handful have taken advantage of them. He admonishes the rest of us to exploit the PhoneGnome platform and develop features. In response to that, PhoneBoy wonders that it could be because there is not much demand for these features. Alec Saunders is a bit more optimistic and sees a new day dawning. My take on this is a bit different.

David quotes Simon Torrence as saying that with PhoneGnome one can “[deploy] far more features than could ever be deployed in IMS, and deploy them within weeks, not years.” The first part of that claim may be true, but I am skeptical about the ability to deploy them quickly. The reason is that PhoneGnome as do almost all standalone VoIP clients project the same limited interface to the users as the PSTN does. If it is difficult to develop feature in PSTN, then there are two main reasons – feature interaction and educating the user to invoke the features. PhoneGnome has not addressed either of them. This may not explain why the developers are missing in the first place; but PhoneGnome will face this issue quickly if David’s wish is granted.

Consider the service David quotes in his entry – Tellme DialTone 2.0. I do not have dialtone in my cordless phone; neither does the cell phone. Why do I need it for VoIP? It is nice that they use speech recognition to dial the number for me. But how do I say “not that John Smith, but the other one”? Wouldn’t having a screen based phone and the ability to select from my address book be simpler and cheaper? I may not have explained why the developers are missing, but I am pointing out that had they come, the situation will be same as it is in PSTN. So I say that we need to pay attention to user interface and simplify feature invocation.

Posted by aswath at 08:04 AM | Comments (5)



Copyright © 2003-2009 Moca Educational Products.