Aswath Weblog

nethead or Nethead?

In a recent article, Russell Shaw described a patent filed by NEC regarding music on hold for VoIP. The crux of the idea is to stream the media using multicast, if the end-point is capable of receiving multicast. Reading that article took me on a memory lane that is more than 20 years now.

As a newcomer to the field, I had “radical” opinions (that wounded me mortally) on ISDN services. One of them was that the Class 5 switch should not decide whether a line is busy or not. It should be decided by the user. The rationale was that since ISDN provides a signaling link to the user, the switch can inform the user of an incoming call independent of whether the user is on a call or not. The idea was rejected out of hand. I didn’t suggest that there is no need for services based on busy condition; just that the user decides the status. So the concern was not that this may lead to loss of potential revenue; it went against the normal mode of operation.

Unfortunately this affliction has been ported to VoIP as well. Many service providers proudly list call waiting and call waiting caller id in their list of features. Voice mail is still offered at the destination, instead of the call originator being told to send an email to a designated account. (If that was the case, then my professional contacts will send their voice mail to my office email account, social friends to my personal account and unknowns to my “junk” email.)

Let us take a look at hold feature in detail. In POTS, there is no way to notify you when I come back after putting you on hold. So you are forced to keep holding the phone and wait. So music on hold is a good service because it takes into account the human psychology. The nature of the network is such that it is not very easy to customize the music. With ISDN, there is no real need because the end-points could use the signaling link. For more than one reason it was not realized. In any event, the bearer channel connection must be kept up during the period of hold anyway; so we might as well pipe some music through it. But the situation is different with IP. The two end-points can have a direct signaling link. So the held party can be alerted when the other party comes on line. Since there is nothing has keeping the media link up; sending media while being held is unnecessary consumption of network bandwidth. That means there is no need for me to play music of my choice and for you to suffer through it. Even if one is compelled to play music, isn’t it better to provide the appropriate URL to the held party and let that user determine whether to listen or not?

A similar movement is developing regarding ringback tones. Why do you have to hear the tone that I selected? Shouldn’t you be selecting the tones that you would like to hear?

So let us not be just Netheads, who port current features and service to the Net; instead let us be netheads, who design services and features appropriate for Net while making sure that customization and individuality are maintained.