EP2034692B1 - Application server for a communication network having optimised interface with media servers - Google Patents

Abstract

The server (AS) has applications (A1-A3) accessible to a communication client, and session context objects (SC1-SC3) storing information e.g. video-on-demand information. Management controllers (D1-D3) are associated with multimedia servers (MS1, MS2), and are provided for being registered close to the objects to notify a modification of a value of information with in the objects. The controllers transform the modification along a protocol contained by the media servers, and transform notifications received from the associated media servers by the modification of the value of the information.

Description

The present invention relates to an application server for a communication network. Such a communication network can in particular be in accordance with the IMS architecture, Internet Protocol Multimedia Subsystem.

The figure 1 illustrates such an IMS architecture in which the invention is likely to register. Application servers are however used in other types of architectures.
On the figure 1 two communication clients C1 and C2 are connected to an IMS communication architecture, via two "proximity" session session control functional elements, P-CSCF1 and P-CSCF2 respectively. They themselves are connected to a "server" functional element, S-CSCF.
These functional elements S-CSCF (for "Serving - Call Session Control Function ") and P - CSCF (for " Proxy - Call Session Control Function ") are defined by the specifications of the IMS architecture of the 3GPP and TISPAN standardization groups.
The sessions established between the two communication clients C1 and C2 are typically managed by the functional element S-CSCF. Some sessions may require the use of an AS application server. The application servers make it possible to make available to the communication network and the different clients a varied set of applications implementing services: management of a multi-party conference, access to pre-recorded announcements, access to multimedia documents, etc.

These application servers are likely to use media servers, MS1, MS2.
Some services inherently require the use of multimedia information (video-on-demand, etc.) and others may require occasional use. For example, you might want to play a media file to announce that the service is not currently available, or just wait for the client.
The storage and management of multimedia files are generally deported on these multimedia servers in order to make the architecture more modular. As a result, the AS application servers create sessions with the appropriate MS1, MS2 media servers.

Currently, there are different kinds of multimedia servers, because of the plurality of manufacturers and technologies, but also because of the different types of media possible (audio, video ... in different formats, encodings ... ).
Also, communications between an AS application server and MS media servers are diverse and make complex the design, deployment and maintenance of an application server.

US 2003/051037 describes an application server for communication network.

The object of the present invention is to solve this problem of the complexity of the application servers.

• Des objets de contexte de session, prévus pour mémoriser des informations relatives à des sessions de communication, et
• Des pilotes de gestion associés aux serveurs de média.
  Ces pilotes de gestion sont prévus
• pour s'enregistrer auprès d'un ou plusieurs des objets de contexte de session afin d'être notifiés de toute modification de valeur d'au moins une des informations au sein du ou des objets de contextes de session,
• pour traduire cette modification selon un protocole compris par le ou les serveurs de média auxquels les pilotes de gestion sont associés, et
• pour traduire toute notification reçue d'un serveur de média associé en une modification de la valeur d'une information d'un ou plusieurs objets de contexte de session.

The application server according to the invention comprises a set of applications capable of communicating with media servers, as part of a communication session. It is innovative in that it furthermore comprises:

• Session context objects, provided for storing information relating to communication sessions, and
• Management drivers associated with media servers.
  These management pilots are planned
• to register with one or more of the session context objects to be notified of any change in value of at least one of the information within the session context object (s),
• to translate this change according to a protocol understood by the media server (s) to which the management pilots are associated, and
• to translate any notification received from an associated media server into a change in the value of information of one or more session context objects.

The session context objects may optionally be distributed among a plurality of agents contained in the application server.
They can also be duplicated on different agents, to ensure fault tolerance.

The invention and its advantages will appear more clearly in the description which follows in conjunction with the appended figures.
The figure 1 , previously commented, represents an IMS communication architecture, in which the invention is likely to register.
The figure 2 , schematizes an application server according to the invention.

According to the invention, an application server comprises a set of applications implementing services and made accessible to the clients and other elements of a communication network by an interface, preferably standardized. This interface can in particular be in accordance with the SIP protocol (for " Session Initiation Protocol") as defined by RFC 3260 of the Internet Engineering Task Force (IETF).

In the example represented by the figure 2 , the application server has 3 applications A1, A2 and A3, and an INF infrastructure.
These applications are accessible to communication clients or to other elements of the communication network, not shown, by an INT interface.
Typically this INT interface is intended to send and receive SIP Session Initiation Protocol signaling messages, as defined by the IETF RFC3260 and other RFCs that later supplemented the original protocol.
These signaling messages can in particular be INVITE invitation messages or other subsequent signaling messages belonging to the same communication session created by the invitation message.
Depending on the service required by the incoming invitation message, it is routed to one of the A1, A2 or A3 applications.
Eventually, the same session can be processed by several applications.

When an application requires the resources of a media server for the processing of a communication session, it creates a session context object within the INF infrastructure.
It is important to distinguish between the communication session and the multimedia session. Any communication session created between the application server AS and another equipment of the communication network does not necessarily generate the creation of a multimedia session. It may also need to create more than one.
The multimedia session is the set of communications between the application server AS and a media server MS1, MS2, between a start-of-session message and a termination message.

In the example illustrated by the figure 2 the application A1 requires the use of two media servers MS1 and MS2, and the application A3 requires the use of a single media server MS1. The A2 application does not use media servers.
To use the MS1 and MS2 media servers, the application A1 creates two session context objects, respectively SC1 and SC3, within the INF infrastructure. The A2 application creates an SC2 session context object.
These context session objects can only be created for a multimedia session and be destroyed at the end of the multimedia session. They can be distributed among a plurality of AGT1, AGT2 agents contained in the INF infrastructure. These agents may for example be themselves distributed on separate equipment.

According to one implementation of the invention, all or part of the session context objects can be duplicated on different agents, to ensure fault tolerance. Thus, for example, copies of the session context objects SC1 and SC2 may be deployed in the AGT2 agent, and a copy of the session context object SC3 may be deployed in the AGT3 agent. These copies contain all the information stored in the original objects.
In normal operation, copies are not active and their behavior is to only synchronize the information they contain with that of the originals. When one of the agents no longer works, the copies stored in the surviving agent become active and manage the multimedia sessions.
Only two agents AGT1, AGT2 are represented in the example of figure 2 but it is obvious that more than two agents can be used.

The distribution of the session context objects and their copy can be performed to ensure a load distribution of the different agents.

This INF infrastructure and the set of session context objects can be a Java infrastructure. It can also be a CORBA infrastructure, specified by the OMG ( Open Management Group ) or any other distributed software infrastructure.

The context represents all or substantially all the information needed for the multimedia session.
It may in particular be information contained in the signaling messages originating from the INT interface, signaling messages originating from the media servers MS1, MS2.
It can also be internal information, in particular developed from information from signaling messages. For example, information about the status of the media server, the time elapsed since the start of an ad played etc.

In this way, applications do not have to manage the storage of contextual information. This allows for greater robustness and fault tolerance: an application may fail and upon restarting retrieve information stored in the session context object (s).
Also, it makes the development and maintenance of applications easier, since it becomes unnecessary to worry about what information should be stored and how.

During a multimedia session, applications can change the value of the information stored in the session context objects. These modifications are made in a transactional way, that is to say so that the so-called ACID properties are respected. It is recalled that ACID properties guarantee atomicity "A", coherence "C", insulation "1" and durability "D".

The INF infrastructure also includes management drivers D1, D2, D3 which are associated with the media servers MS1, MS2. On the example of the figure 2 , the management driver D1 is associated with the media server MS1, and the management drivers D2 and D3 are associated with the media server MS2.
It is expected that a management driver can only be associated with one media server or one type of media server.
If a media server or a type of media server can interface with different protocols, as many management drivers can be provided. For example, the same media server may be associated with a first management driver, specific to the SIP protocol, and a second management driver, specific to SOAP (" Simple Object Access Protocol ").
Eric Burger's " MSCML Protocol: The Key to Unlocking to New Generation of Multimedia SIP Services ", published by Cantata, describes an XML-based protocol for communication between the media server and the application server. The application server may also include a driver compliant with this MSCML protocol.
It is possible to add new drivers within the application server, to accommodate a new protocol, or to interface with a new media server that does not include any protocols for which a driver is already installed.

The management drivers D1, D2, D3 are intended to register with one or more session context objects SC1, SC2, SC3. This record allows them to be notified of any change in the value of a session context object information.

The management drivers D1, D2, D3 also have means for translating this change into a protocol understood by the media server.
Conversely, they have means for translating the notifications received from the media server into a value modification of information within the corresponding session context object.
Applications are also registered with session context objects to be alerted when these changes occur.

To make the invention clearer, we can describe a possible process implemented when the application A1, for example, wants to trigger an action with the media server MS1.
It may for example be to increase the speed of the audio or audio-video media played by the media server, change the language of the ad, choose a music to play etc.

In the description of an example of operation, it is therefore assumed that the multimedia session is already created and a CS1 session context object has already been created.
A request to change the music to play is received by the application A1 by the INT interface. It typically comes from a communication client (a terminal), following a user action.
The application A1 establishes a transaction with the session context object CS1 to modify the value of the information relating to the music to be played. It sets its new value and ends the transaction.
The management driver D1 is registered with the session context object CS1 and is alerted of this modification. He then establishes a message for which it is intended. It is assumed that in this example the media server MS1 comprises the SIP protocol and therefore that the driver of D1 management is able to understand and generate SIP-compliant messages.
The modification is then translated into a SIP message intended to modify the music to be played by the media server MS1.

Such a SIP message may, for example, conform to the specifications of IETF RFC 4240, Basic Network Media Services with SIP .

When the media server MS1 has indeed changed the "playing music" parameter, a message is returned to the management driver D1. This message is also compliant with the SIP protocol. It may for example be a 200 OK message.
The management driver D1 establishes a transaction with the session context object CS1 in order to translate this message into a modification of a value of information stored in the object. For example, it may be to change a status information indicating that the media server MS1 is now synchronized with the setpoint.
The application A1 which is listening to the CS1 session context object is then informed of this modification.

Therefore, in both directions, a fast transmission of events and end-to-end information is achieved.

At the end of the multimedia session, session context objects can be destroyed.

Claims (3)

1. Applications server for communication network, comprising a set of applications liable to communicate with media servers, in the context of a communication session,
   also comprising

   - Session context objects, intended to store in memory information relating to communication sessions,

   - Management pilots associated with said media servers, intended to register with one or more of the session context objects in order to be notified of any modification to the value of at least one of said items of information within said one or more session context objects, to translate said modification according to a protocol comprised by the media server(s) with which said management pilots are associated, and to translate any notification received from an associated media server into a modification of the value of an item of information of one or more session context objects.
2. Application server according to the previous claim in which said session context objects are distributed among a plurality of agents contained in said applications server.
3. Applications server according to the previous claim, in which said session context objects are duplicated on different agents, in order to ensure fault tolerance.

Images