Enabling services seamlessly between internet and legacy domains
Many service requests in the mobile and fixed domains used complex protocols and transactions to retrieve information and provide authentication to allow service use. By adapting and extending components that enable such services, Partitionware enables internet service developers, such as OTTs and alternative service providers to access the same capabilities, extending service reach and increasing the potential for innovation.
We’ve written extensively about how OTT and alternative service providers can enable interaction between the internet and classical mobile domains, using our vVLR to provide hosted mobile alias identities that allow seamless voice and messaging interaction with mobile users. Of course, a wider range of services can be enabled in this way – but there’s another dimension that OTT and alternative service providers are beginning to explore.
In classical and legacy networks, a large number of services were enabled by some specialised signalling protocols, known collectively as the Intelligent Network (IN). There were different versions of this, to accommodate the peculiarities and unique requirements of the mobile and fixed networks. In mobile, these specifications were known by the acronym “CAMEL” or “WIN”, while the terms INAP or AIN was used for fixed, largely depending on whether the network used European / Japanese specifications or US standards.
They were quite complicated but served an essential purpose. Their role was to allow a telecoms switch to pause before completing its routing task and to request instructions and information from a remote server. The functionality helped enable the efficient deployment of, for example, number translation services. Imagine if you dialled a Freephone number (the classic example is to order a pizza). If you dialled from a landline, the switch would know where you were (as you were using a geographic number) and would query the remote service to find out where to route your call.
Freephone numbers have no geographic basis, so they are mapped to a real number with a physical location (think of them as virtual number that provide an alias). By using your location, the service could determine the correct owner of the number and also connect you to your nearest branch. So, if you called for a pizza in Birmingham and the pizza company had a number of branches, the server would provide information that would allow the switch to connect you to the nearest branch. If that branch was busy, you might be held in a queue or routed to the next closest location. In the mobile world, the mobile switch would also know your location (if it doesn’t it can’t connect any calls to you), so the same principles apply but with the added complexity of working out where you really are when you call the service.
Lots of companies used such services without knowing anything about how they work. Today, many web services do something quite similar. For example, a user might click a button on a webpage. This could simply cause them to move to the next level or, it might require an action. In which case, the click triggers a request for more information from somewhere and, when this has been obtained and processed, the desired action results. So, many in the web world are absolutely familiar with the principle of triggering events, requesting service information and acting on the response. In other words, they know all about IN and its relatives. They just don’t know they know them!
In the context of service innovation and extension, this matters, quite a lot. Many web service developers would quite like to be able to extend services to mobile and fixed users or to leverage mobile and fixed capabilities from web-sessions (click to call being a very simple example) but they don’t know how to do so.
The missing link between these domains for such services which require additional information to be obtained and processed happens to be a special function that was conceived to allow new, SIP-based networks to interact with services that had been deployed in legacy environments – and vice versa. This is called a Reverse IM-SSF or (in the other direction), an IM-SSF. Essentially, this is a special gateway that converts instructions from one domain to the other.
Today, this component also provides the opportunity for internet service developers to request new services from the fixed and mobile domains. At Partitionware, we’ve gone a step further and added APIs, so that internet developers can simply include such service requests into their applications. So, if you want to extend new service capabilities to legacy devices – or vice versa, you should talk to us. We’ve made it possible, by leveraging the best of the standards-based telephony world and adding simple interfaces that extend the boundaries of your creative possibilities.
