It was actually rather simple, although it took some thinking about. The triggering of a particular service was typically performed on the basis of the dialled digits and that, coupled with the associated calling line identity (OLI or CLI, depending on where you are from) could be used in the relevant service logic.

The beauty of the system was that it was centralised, with the result that local exchanges didn’t need to be capable of implementing the service logic, but could simply route the call to another destination where the triggers could be recognised and the relevant service executed.

The IN took advantage of centralised service elements, so that there was a single place in which services could be implemented, but any phone connected to the network could effectively access a service.

A typical example of an IN service was the pizza delivery application. In this case, a caller might dial a national Freephone (non-geographic) number for their favourite pizza parlour. The local exchange would route the call to a service switching point which would recognise that the call needed an IN service. It would then send a request to the service control point, requesting information on how to treat the call. In this case, the control point would recognise the non-geographic number and would translate this to a geographic number but would choose one that was nearest to the geographic location of the calling party.

This logic was illustrated in powerpoints the world over. Thus, if you were in Berlin and called your favourite German pizza vendor, you would be connected to the nearest pizza parlour to your location in Berlin. Of course, things changed – mobility entered the equation, companies started using centralised call centres and so on, but IN evolved and still provided useful services that could be managed by the service provider. They generated a lot of revenue and still do.

It was interesting, then, to hear at the WebRTC workshop that preceded the recent IMS World Forum, the classic pizza delivery model being used as an example of services that might be implemented with new WebRTC-based capabilities.

The idea is, of course, simple. Instead of just using geographic location data from an old fashioned geographic number, WebRTC can provide context through browser-enabled communications to enhance the basic service. A consumer might use a WebRTC click to call feature, combined with analytic information and a personal history to select a pizza and have it delivered, so that the call centre agent would know any special details and confirm in a real-time voice session the information required to complete the order.

By integrating with CRM data, the agent could potentially offer a better experience to the caller, just as our favourite web-shops make recommendations based on our browsing and purchasing history. If we can’t complete an online form, then we use click to call to clarify matters, rather than simply being frustrated.

In essence, WebRTC extends the possibilities of familiar services. By using this example, which makes intuitive sense, we see how an old dog can be revitalised by these new tricks – and how blending capabilities and features to create richer services could enhance our experience with retailers.

In the early days of VoIP, the net-heads complained about IN and asserted that it had been a failure. On the contrary, it generated a significant amount of value and is still the foundation of many network services. It’s how prepaid mobile works, for one thing.

Service providers continue to leverage their IN assets and have been deploying upgraded NGIN solutions for some time. Adding WebRTC to the mix broadens the capabilities on offer and points the way to a much more interesting set of services. But, at the end of the day, it’s still a pizza. Perhaps we will come up with a better poster child for such services one day!