GB2470353A - Multimedia gateway using protocol conversion - Google Patents

Abstract

A Multimedia Service Broker (MSB) 1 supplies multimedia content to end users 4 based on user identity and preferences, content format and security policies via a Session Initiation Protocol (SIP) interface and an Application Programming Interface (API) 2, which receives messages in different protocols from various network points (eg. VOIP apps) and converts them to a service query request in a common format. A SIP Servlet container enables the generation of SIP protocol requests, while the API can be used by non SIP Servlet compliant entities, and other protocols (eg. Skype) may be supported by a pluggable protocol adapter. The converted service requests are acted on by a Service Bundle Intelligence Container (SIC) 3 whose decisions are based on defined rules and policies.

Description

Multimedia Service Broker This invention relates to an entity that uses complex rule based policy matching in the combining of various multimedia mediums to provide a holistic service based on users' preference and policy profile. In short, a Multimedia Media Service Broker (MSB) is a network entity that supplies appropriate multimedia content to an endpoint device based on who the user is, their content preferences and what type of media their devices can receive.

The traditional telecommunications industry is currently experiencing its most radical evolution since Sir Alexander Graham Bell invented the telephone in 1876. The development of Voice Over IP (VOIP) protocol suites and emergence of technologies such the Real-time Protocol (RTP) for multimedia exchanges hasted to enormous potential for innovation. The progress of innovation has stalled somewhat due to a number of critical factors: -Legaci networks and services still generate an enormous amount of revenue which continues to represent the bulk of business in the industry. Profit margins are decreasing slowly in a competitive market place but not at significant rates to drive adoption of new technologies.

-As a result of the previous point, the financial leap of faith' for migrating to new infrastructure becomes an inflection point that is driven by revenues. In financially difficult times the bold decisions become increasingly difficult, and service providers simply re-package toll by-pass in a number of different reincarnations -VOIP isan extremely revolutionary technology that requires deep understanding.

Confidence levels and stability in new technology comes with experience. Until a number of high profile success stories are publicly documented the uptake will only consist of tentative baby steps.

There is no doubting the new multimedia technologies that continue to mature and the amount of VOIP minutes being used increases constantly as lP networks increase in quality. The problem to date can be seen as one of not fully utilising next generation networks. Apart from a few high profile exceptions, the majority of VOIP minutes are a result of simple toll-bypass' services where traditional calls break into IP and back to PSTN to provide cheap voice communication that spans geographical boundaries. While this is most certainly a useful service, it is utilising only a fraction of the power that IP based communications can provide.

The Invention will now be described in detail along with accompanying diagrams which Consist of: -Figure 1 shows high level deployment architecture for an MSB.

-Figure 2 shows a detailed composition model of an MSB.

-Figure 3 shows an MSB deployed as a standalone entity.

-Figure 4 shows an MSB deployed in tight integration with a Java Enterprise Edition (Java EE) SIP Servlet container.

-Figure 5 shows an MSB deployed in tight integration with an external server entity using a native Application Programming Interface (API).

In Figure 1, a Multimedia Service Broker (MSB) (1 from Figure 1) is a revolutionary piece of technology that will address all the issues discussed previously. It will foster innovation by encouraging the deployment of new lP applications that can easily be accessed in parallel with existing legacy services. MSB technology will then evolve with the network to provide a central intelligence point that manages and polices user-centric service level. Figure 1 provides a high level illustration of an MSB at the centre of a multimedia network. It is applicable to both enterprise and service provider deployments.

In Figure 1 the MSB acts as a multi-access ingress point (2, 4 from Figure 1) that can accept requests from different network points. It then runs the request through its complex decision making process (3 from Figure 1), potentially interacting with alternative network entities (4 from Figure 1).

Figure 2 provides an illustration of interactions, using various protocols, which can be used in the service bundle (1 from Figure 2) (service bundle is defined in more detail later in this document) selection for a user.

The iterative process can be recursive if required to allow for multiple service bundle selections on behalf of a system user. Figure 2 demonstrates examples of the primary southbound multimedia communication ingress points (2, 3, and 4 from Figure 2) -The MSB (1 from Figure 1) has a pure SIP interface that can receive protocol messages and transform internally into a uniform service query request (5 from Figure 2).

-The MSB (1 from Figure 1) has a SIP Servlet (version 1.1 and later) integration point (2 from Figure 2) that allows two way communications to a compliant SIP Servlet container. The exposure of the Application Router Application Programming Interface (API) by the MSB enables a compliant container to make service query calls that are then fulfilled by the MSB.

In the reverse direction the MSB (1 from Figure 1) is able to use the API interfaces (3 from Figure 2) exposed by a SIP Servlet container which enables the generation of appropriate SIP protocol requests (As of SIP Servlet 1.1 and later, the SipFactory' interface allows third party entities to control the SIP Serviet API remotely.).

-The MSB (1 from Figure 1) also has an exposed API interface (4 from Figure 2) that can be utilised by non SIP Servlet compliant entities. This interface allows similar functionality to that provided to a SIP Servlet container (discussed in previous paragraph) in that a third party server can supply contextual information to an MSB (1 from Figure 1) using the native API (4 from Figure 2) and receive a return value containing the resultant routing decision. For example, this could be tight integration to a Session Border Controller (SBC), JAIN Service Logic Execution Environment (SLEE) or a Serving Call Session Control Function (S-CSCF) from the IP Multimedia Subsystem (IMS) reference architecture.

-The MSB (1 from Figure 1) provides a pluggable network protocol interface framework (5 from Figure 2) that allows for additional adapters that extend the range of network protocols supported. The default network protocol Interface support is the Session Initiation Protocol (SIP) but might also be interactions with other network entities and protocols such as XMPP (Google), Skype and Microsoft.

The MSB northbound interfaces (6 from Figure 2) provide a link into varying business technologies that aid the service query process for a user within the network. Interactions such as RTSP (Real lime Streaming Protocol), HTTP (Hypertext Transfer Protocol), and Diameter are but a few examples that utilise the programmable data transformation layer (7 from Figure 2). The deployer (the person in charge of an MSB and its entire configuration) can choose which combination of protocol adapters should be included as part of a deployment and can also be safe in the knowledge that future additions and subtractions to the supported list can easily be configured.

At the core of an MSB, sitting in the middle of the various southbound communication interactions and pluggable northbound interfaces is the Service bundle' Intelligence Container (SIC) (8 from Figure 2). The SIC takes input of the incoming service based requests (2, 3, 4, 5 and 6 from Figure 2) which have been transformed into a common form and then acted upon by the configured SIC programming language (which is interchangeable, for example java based/xml script etc.). The SIC language provides an appropriate rule set for making decisions on the transformed requests (for example, an appropriate scripting language). The SIC makes appropriate security and policy checks to ensure that the user making the request is authenticated and is authorised to perform the functionality. In certain cases the functionality may also be depend on the specific authenticated user. The SIC then passes the request through the Service bundle' Intelligence processor (9 from Figure 2) to determine the next course of action. It could be determined, depending on the role of the MSB, that: -A result is returned to the client entity which used one of the MSB API interfaces (2, 3, and 4 from Figure 2).

-A Session Initiation Protocol (SIP) request (or any other protocol that has been deployed using (5 from Figure 2)) is routed onwards to an appropriate location (or even responded to that request using SIP protocol) The transformed request is passed to an appropriate adapter such as RTSP, Diameter and/or HTTP (6 from Figure 2).

Any number of combinations from the previous list can be used to provide both simplistic and extremely complicated decision logic. At the heart of the SIC is a pluggable Service bundle' language framework (9 from Figure 2) that allows decision making rules to be defined and applied appropriately on a request. The flexible approach allows for multiple languages to be used within a deployment and even on a single request. It could be a standardised business logic language such as the BPEL, java code, or a proprietary scripting language depending on requirements. The term Service Bundle (1 from Figure 2) represents how the MSB will treat a new request for service from any of its active interfaces for a specific user.

The final output of the complex response process is a series of decisions that influence the destination of the service request. It is the combination of such decisions for a user of the system that influence the different adapters that are triggered and ultimately the end-user multimedia experience.

The MSB can fulfil a number of roles in a network with varying levels of complexity: -In Figure 3 it can exist as a standalone entity that receives a request, applies the appropriate decision making rule set'and dispatches the request to the appropriate location (*note -which may not neceSsarily be a SIP entity but could be via one of the alternatively deployed connectors).

-In Figure 4 it can exist tightly integrated with a Java Enterprise Edition (Java FE) SIP Sérvlet Application Server. Using the standardised Application Router interface a SIP Servlet container can request a processing decision from the MSB. The request is then transformed and then appropriate decision making rules are applied. The decision made by the MSB is then returned to the SIP Servlet container who invoked the interface.

-In Figure 5 it can also exist with non-lEE SIP Servlet servers (such as aSession Border Controller (SBC) orJAIN Service Logic Execution Environment (SLEE)) through a native interface.

The various deployment options provide a wide range of applicability to evolving next generation networks of all kinds including both enterprise and service provider. The intelligent service decision point applies configured rule sets after requests arrive at the MSB which are then applied to an incoming service request. This allows for both new IP based services and shoed legacy applications to live in harmony in the context of network communication.

Claims (11)

1. Claims 1. A Multimedia Service Broker (MSB) software entity that is able to receive service requests, transform and process those requests based on configured logic and user preferences and policies, and provides a response that will dictate the multimedia experience applied to the request.
2. 2. An MSB according to claim 1, contains a Service-bundle Intelligence Container (SIC) that provides functionality for configuring how service requests and responses are processed.
3. 3. A SIC according to claim 2 consists of the language syntax and grammar, which is interchangeable, used to describe how service requests and responses are processed.
4. 4. The SIC according to claim 2, has a common interface for specifying the language syntax and grammar used.
5. 5. A MSB according to claim 1, contains Application Programming Interfaces (API) for adding transport and protocol adapters for communicating with external multimedia sources used bythe SIC.
6. 6. A protocol adapter according to claim 5, receives a request and uses the APIs according to claim 5 to transform into the common format used by an MSB.
7. 7. A protocol adapter according to claim 5, generates a response and uses the APIs according to claim 5 to transform into the appropriate adapter specific format used by an MSB.
8. 8. A transformed request according to claim 6, will be authenticated according to configured security policies before being passed to the SIC to confirm the identity of the user initiating the request.
9. 9. A transformed request according to claim 6, will be checked for authorisation according to configured security policies before being passed to the SIC, to confirm the user identified according to claim 8 is permitted to make the request.
10. 10. A transformed response according to claim 7, before being passed to the adapter, will be authenticated according to configured security policies.
11. 11. A transformed response according to claim 7, before being passed to the adapter, will be checked for authorisation according to configured security policies.