A METHOD, A SYSTEM AND A PROXY FOR INTER-SERVICE- PROVIDER-I P-BACKBONE

Field of the Invention

This invention relates to an inter-service-provider-IP-backbone, where a SIP service is delivered via an IPX proxy, and particularly to a situation in which said terminals support different SIP services.

Background of the Invention

The term "inter-service-provider-IP- backbone" refers to a network that enables interworking between 2G and 3G networks such as the GPRS (General Packet Radio Service) and UMTS (Universal Mobile Telecommunications System) networks. An example of the inter- service-provider- IP-backbone is GRX (GPRS Roaming exchange) network, which is provided for GPRS roaming. The GRX is a private IP backbone, and it is arranged to transport GPRS roaming traffic between a visited and a home PMN (Public Mobile Network). At a minimum, a GRX Service Provider consists of a set of routers that are made up of the links connecting to the GPRS networks and the links connecting to other GRX nodes. In addition to the GPRS roaming, the GRX is also used for e.g. 3G roaming, WLAN roaming and MMS interworking.

The purpose of the GRX is to provide a more practical solution for implementing a secure connection between operators. Practicality means that thanks to the GRX there is no need to build separate tunnels or other systems between all operators, whose number is currently approximately several hundreds, but to implement a secure network, which is differentiated from the Internet or other irrelevant network parties. The secure network has to be a closed network and to remain closed in order to be also reliable and in order not to require additional security features within the network. The closed network has other advantages as well. For example, it is possible to secure the quality of the service as well as both the availability and the scalability

of the network. Operators providing the GRX network are called GRX operators, and they do not need to be but may be mobile operators as well.

The GRX uses addressing that is similar to that used in the Internet. However, the addressing is completely differentiated from the Internet. The GRX operators are in charge of controlling and monitoring that addresses allocated for the GRX are not routed in the Internet, and vice versa. If this still happens, it can be assumed that a leak or a configuration error has occurred. The GRX also has a DNS hierarchy that is also completely differentiated from the Internet, and that is aimed only for a use of nodes and roaming connections between operators. In other words, it is required that nothing should be resolved from the Internet within the GRX, and nothing should be resolved from the GRX within the Internet. Therefore in the sense of DNS and routing, the GRX and the Internet are diverse and apart from each other.

It is advantageous to have the GRX separated from the Internet, but there are also some disadvantages. For example the use of similar domains used in the Internet is restricted. For instance, such addresses that are understandable to the end users, do not work in the

GRX. This is because the GRX has been designed purely between operators, and because the type of cryptic forms used has been less important, because the users have been the operators. However, it will be appreciated that requesting the end users to utilize these forms is not desirable.

At present manufacturers develop their services that are based on the SIP/IMS (Session Initiation Protocol/IP Multimedia Subsystem) system.

The IP Multimedia Subsystem is an open multi- media architecture for mobile and fixed I P services. The aim of the IMS is to provide services, which can be executed by the users, when they are roaming as well as in their home networks. The IMS will comprise means e.g. a proxy for directing traffic between operators. This kind of a proxy is located in the network in order to ease routing, testing and commercial contracting.

The proxy is thus arranged to operate as a transmitter for SIP/IMS based services (later referred as SIP services).

Unstandardized services - even though they relate to similar services - are not usually compatible with each other. An example of such service is a video service which enables communication via a mobile network by video and audio means. This kind of communication means that it is possible to view live video or a video clip during a voice call, which video can be one-way or two-way depending on how many directions the video is transmitted in. Both parties participating in the communication can see the same video and discuss it. In order to use the video service, the users must have terminals that are capable of video transmission. In other words, the terminals have to support the media transport in question. In addition, when the media service is a network service, the terminal also needs to be subscribed to a network operator offering said service.

However, if the services supported by the participants are not the same, they are not necessarily compatible with each other. Therefore users supporting different video services cannot have video sharing between those services. It is easily realized that this kind of incompatibility is a drawback. Preferably, anyone should be able to have video communication with anybody, regardless of the terminals being used, as in normal voice calls and e.g. short messaging service.

Because the aforementioned services are currently in progress, less attention has been paid to compatibility issues. Basically it is possible to overcome the incompatibility by installing all the required software programs in the terminal, which software programs are needed for video transport with other terminals. However it is clear that this kind of installing would increase the memory consumption in the terminal. In addition, in some cases the installation is not allowed, for example, if the terminal is locked, or if the user does not have required rights for the installation, or further, if the required application is not available anywhere else but only in the terminals in which the manufacturer has originally installed it. In addition, the usability may be impaired,

because the user has to browse between different programs in order to view the video with another user.

Therefore, what is needed is an improved system which allows SIP service sharing between terminals, even though the terminals have different media transport capabilities.

Summary of the Invention

The aim of the current invention is to provide a method, a system and a proxy by means of which SIP services become possible between terminals with different capabilities.

The method according to the invention is mainly characterized in that a type of the SIP service is determined by at least a portion of the data, capabilities of the receiving terminal are defined, whereby if the receiving terminal is capable of handling the determined type, the data is transmitted to the receiving terminal, but if the receiving terminal is capable of handling one other type of SIP service instead of the determined type, the data is converted to comply with said other type and the converted data is sent to the receiving terminal.

The system according to the invention is mainly characterized in that said system is arranged to determine a type of the SIP system by at least a portion of the data, and to define the capabilities of the receiving terminal, whereby if the receiving terminal is capable of handling the determined type, the system is arranged to transmit the data to the receiving terminal, but if the receiving terminal is capable of handling one other type of SIP service instead of the determined type, the system is arranged to convert the data to comply with said other type and send the converted data to the receiving terminal.

The proxy according to the invention is mainly characterized in that said proxy comprises conversion means capable of determining a type of the SIP service by at least a portion of the data and defining capabilities of the receiving terminal, whereby if the receiving terminal

is capable of handling the determined type, the conversion means is arranged to transmit the data to the receiving terminal, but if the receiving terminal is capable of handling one other type of SIP service instead of the determined type, the conversion means is arranged to convert the data to comply with said other type and send the converted data to the receiving device.

Thanks to the invention SIP services, such as video service, from one operator to another can be arranged in a network element located between operators, in a situation in which different operators or subscribers use solutions of different manufacturers, which solutions are not compatible with each other. As a result of this, the need for several service programs in one terminal can be eliminated, because the user needs only one software to his/her terminal for the proxy. The proxy will then make the necessary operations for transcoding the services with the opposing terminal.

In addition, when the IPX proxy is utilized for the transcoding, the operators do not need to implement any new network components and therefore the operators do not have to carry out any maintenance or updating operations. Further, there is no need to interfere with the routing between operators, because the routing passes the IPX proxy in every situation.

Description of the Drawings

The current invention will be described in more detail by means of following detailed description and the attached figures, in which

Figure 1 illustrates a system according to one example of the current invention,

Figure 2 illustrates a simplified example of solving capabilities of a receiving terminal for a SIP service,

Figure 3 illustrates a simplified example of sharing a SIP service between terminals, and

Figure 4 illustrates an example of the complete procedure of the current invention in a simplified manner.

Detailed Description of the Invention

The current invention relates to the inter-service-provider-IP-backbone, e.g. GRX network that is common to the existing operators. Another example of the inter-service-provider-IP- backbone is the CRX network (CDMA Roaming exchange). The purpose of the GRX is to deliver traffic between operators via a proxy system, e.g. an IPX proxy, which is an extended version of a SIP proxy. In the invention the SIP service is transcoded for terminals having different support for the SIP service. The transcoding relates to a process of converting media from one format to another. In the case of a video service the transcoding includes e.g. converting the codec used for the video to another format (e.g. from H.263 to MPEG-4); or the transcoding may relate to the bit rate, to the frame size, to other codecs, to transport protocols, or to the RTP- packet being used. The skilled person will also appreciate that the transcoding can be targeted to other matters as well. In this invention the IPX proxy, which is already located in the GRX network and which is already used as a delivering means, is provided with transcoding means in order to have the IPX proxy operate also as a transcoding element. Even though the transcoding means can be arranged in a separate device connected to the IPX proxy, the arrangement within the IPX proxy is more advantageous, because of the smaller number of network elements.

In order to implement the transcoding for the terminals, the IPX proxy may comprise an internal database (e.g. a SQL database), in which features of different SIP services are stored. The IPX proxy may also be connected to such a database. The IPX proxy is arranged to carry out the transcoding in real time. It will be appreciated that the internal operations, which relate to the transcoding, and any other operations

made by the IPX Proxy, such as changing an OPTIONS field, do not need to comply with any standards. The interface shown outside by the IPX proxy should, however, follow common agreements and specifications. In other words, the IPX proxy can do internally almost anything, if it externally follows the existing standards.

As said, the IPX proxy stores information on features of different SIP services, and therefore it can transcode the services as required. In this description, the term "session" refers to the exchange of data between participants. The SIP service sharing relates to a situation in which two participants i.e. terminals are using the same service. Sharing means that each the users of all terminals participating in the SIP service can see, hear and possibly modify the media substantially at the same time. The SIP service can relate to the services of one medium, such as only audio, images, speechless video, games, files or text, or to a combination of media, such as a video having both video and audio, games with sound etc. The service can be identified by determining the type of the SIP service from the SIP message. The services that are the main objects of the current invention, are usually unstandardized services. However, this is not always the case. There are also such standardized services that are not compatible with each other if, for example, the services are provided by different network types. Therefore, the problem solved by the current invention is to get parties speaking different languages to communicate with each other.

An example of a system according to the current invention is illustrated in figure 1. In this example, the SIP service is a video transport service. In figure 1 , electronic terminals 101 , 201 are subscribed to operator networks 100, 200, respectively. The operator networks 100, 200 are interconnected by means of e.g. an IPX/GRX network 300 where also an IPX proxy 350 is located. When video communication with a receiving terminal 201 is desired, the sending terminal 101 transmits (1 ) an SIP OPTIONS message to the IPX proxy 350. The IPX proxy 350 makes a query (2) to the receiving terminal 201 and uses the OPTIONS message in order to solve the capabilities of the receiving terminal. When the SIP OPTIONS message is received from the IPX

proxy 350, the receiving terminal 201 replies (3) that it can use a vi deo service B, which is provided by the operator 200.

When the response for the OPTIONS message is received by the IPX proxy 350, the sending terminal 101 may transmit (4) an SIP initiation message, i.e. an SIP INVITE message, for the video communication towards the receiving terminal 201. The SIP message comprises a message body containing information provided by the Session Description Protocol (SDP). The IPX proxy 350 utilizes the SDP portion of the message in order to determine (5) which kind of specific video service the sending terminal 101 is asking for. After determining that the sending terminal 101 is asking the receiving terminal 201 to communicate by means of a video service A, which is provided by the operator 100, the IPX proxy 350 retrieves the capabilities of the receiving terminal 201 from its database in order to carry out the required transcoding.

The IPX proxy 350 is, after retrieving the capabilities of the receiving terminal 201 , arranged to modify (6) the INVITE message identifying the video service A and sent by the sending terminal 101 into such a message, which identifies the video service B. The modified INVITE message is transmitted (7) to the receiving terminal 201. Now the INVITE message is in such a format that is supported by the receiving terminal 201 , and therefore the receiving terminal 201 can response to the proxy affirmatively e.g. by a "200 OK" response. The response from the receiving terminal 201 is received by the IPX proxy 350, indicating that the receiving terminal 201 supports the video service B. The IPX proxy 350 replaces (8) the information on the video service B with information on the video service A in the response, whereby the message affirming the use of the video service A can be transmitted (9) to the sending terminal 101. Due to this communication, the sending terminal 101 can transmit a video data stream towards the receiving terminal 201 via the IPX proxy 350 in a video service format, which is supported by the sending terminal 101 , and the receiving terminal 201 can receive the video data stream in a video service format which is supported by the receiving terminal 201. This is possible because the

IPX proxy 350 is arranged to convert the video service for the video data stream between the terminals 101, 201.

The figure 1 illustrates an example of the system, in which the sending terminal makes the OPTIONS query. The person skilled in the art will appreciate that in some situations the proxy may carry out the OPTIONS query completely by itself. An example is a service which does not need any capability query for itself, but assumes that the user knows to whom the connection can be formed. In other words, the sending terminal 101 does not thus send the OPTIONS query, but transmits the INVITE message outright. In this example, the proxy must take care of that it will be informed on the capabilities of the receiving terminal 201. This information is needed in order to form such an INVITE is formed that can be received by the receiving terminal 201. In practice, the proxy should ask the receiving device 201 by the OPTIONS method (or e.g. INFO method), which service the receiving device 201 supports. If this was not done, the sending terminal 101 could propose a service that the receiving terminal 201 does not support, whereby the connection may get cut of.

Figure 2 illustrates sharing a SIP service between mobile terminals MT1 , MT2 in an inter-service-provider-IP-backbone. At first, voice communication (CS voice), such as e.g. a circuit-switched (CS) phone call is initiated between mobile terminals MT1 , MT2. After the phone call has been initiated, the sending mobile terminal MT1 wishes to determine the video service capabilities of the receiving terminal MT2 by sending an OPTIONS message towards the receiving terminal MT2. In the inter- service-provider- 1 P- backbone, the message travels via an IPX proxy (PX), which transcodes the OPTIONS message to such a form that is understood by the receiving terminal. After the capabilities of the receiving mobile terminal have been solved, a session for the SIP service is set up by means of an INVITE message. This situation is illustrated in figure 3.

Figure 3 illustrates the CD voice call, during which the sending mobile terminal MT1 sends an INVITE message (Request-uri: TEL URL or

SIP-URI)/SIP to the receiving terminal MT2 via the IPX proxy PX, which transcodes the message according to the capabilities of the receiving terminal. The receiving terminal MT2 is capable of understanding the transcoded INVITE message, and the response "100 Trying" is sent to the sending terminal MT1 , which response indicates that the receiving mobile terminal MT2 has not yet been located.

When the receiving terminal MT1 has been located, the sending terminal MT1 is notified with "180 Ringi ng". When the receiving terminal MT2 approves the SIP service with the sending terminal MT1 and responses with 200 OK/SDP, the SDP of the response part indicates the capabilities of the receiving terminal MT2.

In figure 4, the complete process for the current invention is illustrated in a simplified manner. It can be seen from the figure 4 that the capability query procedure, the invitation procedure, RTP, RTCP and SIP BYE/200 OK travel via the IPX Proxy PX. The CS voice call may remain after the video transmission (RTCP BYE) and the SIP session (SIP BYE) have been ended. The call will be finished afterwards in conventional way by transmitting DISCONNECT, RELEASE and RELEASE COMPLETE messages between the sending terminal MT2 and the receiving terminal MT1.

The previous figures 2—4 relate to an example of the video service. A person skilled in the art will appreciate that other types of video services, than those presented in the figures 2—4, are possible depending on the manufacturer, and these different services should be taken into account by the IPX proxy. It is therefore possible, for example, not to have the CS voice call, and/or that some other procedure is used instead of the OPTIONS.

The SDP information of the OPTIONS procedure, i.e. the information on the capabilities of the terminal, which may be modified by the IPX proxy will be described next by means of an OPTIONS example.

Similar data may be included to the INVITE message, if required by the service being used.

OPTIONS example (200 OK) (Feature Tag may be included in Contact header) m=video 0 RTP/AVP 96 a=rtpmap:96 H263- 2000/90000 m=audio 0 RTP/AVP 97 (NOTE: audio as part of a streamed video clip) a=rtpmap:97 AMR/8000

^■ m=message 0 TCP/MSRP ^* a= accept- types:

- image/jpeg

- image/gif - video/3gpp

- application/msword

- application/vnd.ms-excel

- application/vnd.ms-powerpoint

- application/vnd.ericsson.wswb - application/pdf

- text/plain

- whateveritis a=maxsize:max-size- value

Depending on the situation, the IPX proxy 350 does not necessarily need to be always in charge of the conversion of the INVITE message. An example to be mentioned is such a situation, in which the receiving terminal can answer the INVITE message itself by sending its capabilities to the IPX proxy. Therefore it is sufficient for the proxy only to modify the response in such a manner that the sending terminal can assume that the recipient supports the same video service that the sending terminal does, although the proxy, in fact, converts the service to be suitable for the recipient. In such a situation, an INFO method could travel between terminals. The purpose of the INFO method is to allow the carrying of session related control information generated during a session. The IPX proxy should be flexible enough to enable -

depending on the devices - both the transcoding of the INVITE message, and leaving of the INVITE message untranscoded, when only the media content is transcoded.

By using the IPX proxy between terminals, it is also possible to provide information on the recipient's capabilities to the sending terminal. For example, when a response from the recipient is to be transmitted as a transcoded version to the sending terminal, the sending terminal may be asked, if it wants to use this kind of session.

One possibility for the required query could be a presence service, by means of which it is possible to know the capabilities of the recipient, and the proxy could modify the INVITE message targeting the recipient according to the capabilities in question. The presence service is used to notify whether other parties are able and willing to accept communications. The proxy may also have an internal database for storing the capabilities of recipients, for example, as cached from a previous query. Therefore, it is not necessary to carry out the query in question, which saves time. In addition, the proxy may have been given information on the capabilities of the terminal by the operator, whereby it is not necessary to perform the query.

In the GRX network structure there is a possibility to have direct connections or connections that are directed via the IPX proxy. When a direct connection is used, the transcoding capability of the IPX proxy will be passed over. However, in order to enable the usage of the transcoding with direct connections, it is still possible to route the traffic via the IPX proxy.

It can be observed that as a result of the current invention the user does not need several software programs for different media transport services. One software program will be sufficient, because the proxy can handle the transcoding with the other terminal. The transcoding provided by the proxy is transparent to operators and other service providers, because they are not expected to do any additional investments, nor to change routing to the GRX/IPX network in order to

use the service given by the proxy. The current invention can be used as a value added service. The use of the solution is not required, but it can be provided between certain operators and be based on agreements until the services are developed so that they are compatible.

In the previous example, the video service was used as an example of SIP services. It will be appreciated by the person skilled in the art that other media services are suitable for the current invention. Examples of such services include e.g. games or file sharing. It should be noticed that if the recipient supports such a SIP service that provides both a video communication and file sharing, and the sending terminal supports such a SIP service that only provides one of those, it is possible to either remove the unsupported media from the communication, or to transcode the unsupported media to comply with some other service in the sendi ng terminal.

The transforming is not necessary in every situation if the terminals have the same codec e.g. a video codec. However in such a situation the proxy may solve other compatibility problems such as e.g. different signalling before the connection may work. Even though the IPX proxy is used as an example of a location for the functionality of the current invention, it is obvious that the solution can be utilized in another device. Examples include a border gateway situating between operator network and GRX/IPX, or a Session Border Controller device, which can implement the incompatibility requirements between different video services.

Furthermore, the aforementioned systems are examples of the current invention; however, a person skilled in the art will appreciate that numerous other databases and systems may suitably communicate with the present solution to provide enhanced functionality. The foregoing detailed description is thus provided for clarity of understanding only, and it should not be read as a limitation of the claims herein.