KR101458638B1 - Interworking method in converged ip messaging service - Google Patents

Abstract

The present invention relates to an interworking method of a Converged iP Messaging service (CPM) server in a unified messaging service, and more particularly, to a method of interworking a CPM Checking whether the CPM service is supported by the recipient terminal, checking whether the CPM service is supported by the recipient terminal, and displaying the supported supportable service to transmit the CPM content. do.

CPM

Description

INTERWORKING METHOD IN CONVERGED IP MESSAGING SERVICE [0002]

The present invention relates to a unified messaging service, and more particularly, to a method and system for interworking between a unified messaging service and another messaging service.

Commonly used messaging services include short message service (SMS), multimedia messaging service (MMS), email service, and instant messaging service. Although each messaging service is provided based on a different technology, there are a number of parts where the above messaging services overlap each other in terms of the user experience. For example, text messages may be sent through all messaging services, and services other than SMS may transmit multimedia content.

In consideration of the fact that the user experience is duplicated, the Open Mobile Alliance (OMA) has recently introduced a Converged IP Messaging Service (CPM) service based on Session Initiation Protocol (SIP) and Internet Protocol ') Is a new service. The purpose of the CPM service is to provide key features of existing messaging services in a single messaging service. Accordingly, even if the user uses the CPM service, the user can experience the user service provided by all the existing messaging services, and it is also possible to exchange messages with all existing messaging service users.

A schematic configuration of a system for providing such a CPM service is shown in Fig. 1, the CPM system includes a CPM client 10, an IWF (interworking function) 20, a message media storage 30, a converged address book 40 A user preference storage unit 50, a CPM server 60, a Session Initiation Protocol / Internet Protocol Core Network (SIP) 70, and the like.

The CPM client 10 is typically included in the terminal and provides interfacing between the CPM service and the user. That is, the CPM client 10 plays a role of processing the request of the user. For example, when a user creates a content and requests transmission, the content is converted to fit the CPM service, included in the SIP MESSAGE, and transmitted to the SIP / IP core network 70. Or receives a content transmitted from another client, confirms and verifies that the content is properly received, and transmits the content to the user. Thus, the CPM client 10 can be regarded as a point of contact between the user and the CPM service.

The CPM server 60 is a server that handles the requirements that the CPM client 10 transmits through the CPM conversion interface. The CPM server 60 applies a service provider or a policy set by the user to the CPM contents delivered from the CPM client 10. [

The IWF 20 converts CPM content to another messaging service so that the message content transmitted by the originating CPM client, that is, the CPM content, can be processed by a messaging service other than the CPM service, and provides the content of another messaging service Upon receipt, the format of the content is changed so that the CPM service can process it. The IWF 20 is connected to the CPM server via the CPM-IW interface and is connected to other messaging services through an interface provided by the messaging services.

 The message / media storage unit 30 stores messages that the user is absent or is delivered to the user by the user's setting. The integrated address storage unit 40 is a kind of phonebook and includes a contact list and informs the user of presence information of each access information.

The SIP / IP core network 70 is a low-level network supporting the necessary Session Initiation Protocol (SIP) and Internet Protocol (IP), and exists between all the components described above and is responsible for routing all messages. As an example of the SIP / IP core network 70, there is an IMS (IP Multimedia Subsystem).

The CPM service provides messaging services by interworking with existing messaging services. Accordingly, in the CPM service environment, the caller originates the CPM contents without considering the type of the messaging service or the preference of the recipient, and determines whether the CPM system is interworking or not and the type of messaging service to be interworked And provides a messaging service.

In order to determine whether the CPM system is interworking, to determine the type of messaging service to be interworked, and to determine which network to perform interworking between the receiving network and the originating network, the CPM system determines presence Various criteria can be used to acquire information and make all decisions based on it, and various application algorithms may exist for each criterion.

Therefore, it is necessary to define the appropriate criteria for the most appropriate interworking and to define the application algorithms that can exist for each criterion.

In the interworking method of a Converged iPMessage service (CPM) Conversation Server in a Unified Messaging service according to various embodiments of the present invention, when a CPM content is received from a sender terminal, a CPM service is supported in a receiver terminal to receive the CPM content Checking whether the CPM service is supported by the receiver terminal, checking whether the receiver terminal can support the CPM service, displaying the confirmed supportable service, and transmitting the CPM content ≪ / RTI >

delete

In the present invention, when content to be delivered is received in an environment such as a CPM service, it is determined whether contents need to be switched through an interworking function (interworking function), and if necessary, Side network. ≪ / RTI > With this system, the advantage of the present invention is that the sender can automatically send the CPM contents to the recipient without the need of knowing what service the subscriber has subscribed to and what service they want to use.

Hereinafter, a preferred embodiment of the present invention will be described in detail with reference to the accompanying drawings. It is to be noted that the same components in the drawings are denoted by the same reference numerals and symbols as possible even if they are shown in different drawings. In the following description of the present invention, a detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present invention rather unclear.

First, In the embodiment  follow CPM  Services are different Messaging  Service and Inter The criteria used in the walking process ( criteria ).

The criteria used in the present invention include service level agreements (SLAs), presence information for recipients, SIP URIs associated with recipient addresses, iFC (initial filter criteria), XML Document Management Server (XDMS) Information, and service provider policies.

In order to send and receive content between the source and destination networks, a service level agreement (SLA) must be established between the service providers of each network. Here, the originating network is a network that provides a messaging service used when a content is originated, and the receiving network is a network that provides a messaging service used by a content recipient. If there is an SLA between the two networks, the two networks provide an equivalent level of service, meaning that there is a component in each network that has a corresponding component or corresponding function.

For example, when a CPM user generates content, if the CPM system knows that a network of the messaging service to which the recipient is registered, that is, a receiving network, and CPM service and service level agreements, Service provider. Thus, it can be seen that the interworking is also possible in the receiving side network.

The presence information is information set by the user, and includes information necessary for interworking in addition to the status information of the user. That is, the presence information includes a type of a messaging service to which the user subscribes, and a user preference. The type of messaging service to which the user subscribes may be, for example, a CPM service, an MMS, a POC, or an IM service. The preferences include whether the user is allowed to interwork and information about the messaging service to be interworked. That is, preferences include the type of one or more messaging services to be used in interworking, the priority of each messaging service to use in interworking, and the like. For example, when the user subscribes to the CPM service, the type of the user's subscribed service becomes the CPM service. The SMS, MMS, and POC services can be set as a messaging service to be interworked by the user and can be assigned a priority of 1, 0.5, and 0.2, respectively. When transmitting CPM contents to a user having such presence information, the CPM contents are preferentially converted into SMS and transmitted. Therefore, using the presence information, the outgoing messaging system can determine whether interworking is performed or not and the type of messaging service to interwork with.

On the other hand, there is a method of changing the receiving address to a general-purpose routable SIP URI (Address translation to a globally routable SIP URI). In order for content to be delivered over the SIP / IP core network, content must be created for the SIP protocol. When creating the content, there is a field called Request-URI, which indicates the address to which this content should be forwarded (that is, the address of the recipient of the message). Globally routable SIP URI), but the content can be delivered over the SIP / IP core network. If such an address is not entered (TEL URI), the SIP / IP core network checks for a SIP URI that matches the address through a method called DNS / ENUM lookup (DNS / ENUM lookup). However, if the recipient is not subscribed to a SIP-based service such as CPM, PoC, or SIMPLE IM, then there is no such SIP URI, so no SIP URI can be found through the DNS / ENUM lookup performed by the SIP / IP core network. In this case, the content can not be delivered through the network provided by the SIP / IP core network without the SIP URI, so that the calling system can directly transfer the contents to the interworking function on the calling side so that the contents can be received by the receiver .

Alternatively, there is an initial filter criterion (iFC). When any SIP-based content (eg CPM Message generated on the basis of a SIP protocol) is delivered to the SIP / IP core network, the SIP / IP core network first compares the characteristics of this content with the stored initial filter criteria, Determine which server (application server) can deliver the contents. The following is an example.

CASE method = MESSAGE AND header = Accept-Contact = + g.oma.cpm

   THEN: ROUTE request to the specified CPM Conversation Server Terminating Port Address

CASE method = MESSAGE AND header = Accept-Contact = + g.oma.cpm-iw

   THEN: ROUTE request to the specified CPM interworking function Terminating Port Address

CASE method = MESSAGE AND header = Accept-Contact = + g.poc.talkburst

   THEN: ROUTE request to the specified PoC Server Terminating Port Address

The first line of the example is forwarded to the CPM Conversation Server address in the same network if the content is a request of "MESSAGE" and the "Accept-Contact" header is "+ g.oma.cpm" It means to ask. If the "Accept-Contact" header is "+ g.oma.cpm-iw", it will be delivered to the CPM interworking function. If it is "g.poc.talkburst", it will be delivered to the Poc server. There is a corresponding iFC for each user. When the SIP / IP core network is in the originating network, it uses the originating iFC of the caller and the receiving iFC when it is in the receiving network.

Routing can vary depending on how the service provider configures this iFC. For example, if you set the criteria such as "g.oma.cpm-iw", which is used for interworking, you do not send CPM contents to the receiving network when interworking is required. Instead, the interworking function .

Next, the information in the XML Document Management Server (XDMS) is available. When the CPM content is delivered to the CPM Conversation Server, the XML document management server must know the recipient's preferences and other information subscribed to the service provided by the XML document management server, Can be transmitted properly. In particular, the recipient may request that the CPM content be switched and received via another service (e.g., SMS) despite having subscribed to the CPM service at its own preference. An XDM server that stores user preferences and service policies, and the like. And determines whether interworking should be performed in the receiving-side network according to the information thus obtained.

Finally, there is a method according to the service provider's policies. In some cases, multiple selections may be made applying the methods and criteria described above. (For example, interworking is possible on both sides (both the source and destination) where interworking is required). If you do not know which one is better without additional methods or criteria. It decides which option to select according to the policy set by the service provider.

Hereinafter, the operation of the system for determining interworking will be described.

Based on the above-described methods and criteria, a CPM Conversation Server (CPM Conversation Server) that determines whether interworking is performed when one of the elements in the CPM structure shown in FIG. 1 is received, Lt; RTI ID = 0.0 > SIP / IP < / RTI > core network.

The basic operation of a CPM Conversation Server receiving CPM content is as follows.

In step 203, the CPM Conversation Server checks whether there is a service level agreement between the recipient service provider and the originating service provider corresponding to the recipient address. If there is a service level agreement, it means that the receiving side network also supplies the CPM contents, which means that interworking is also possible in the receiving side network. If there is no SLA in step 203 for the next test, then the CPM content can not be received on the receiving network. Then, the process proceeds to step 207.

In step 205, a method using the presence information for the recipient described above is used to find out what services the recipient can use, and in particular which service he wants to receive the CPM content. If the contents are known, proceed to step 207 for the next test. If these contents are not known, there is no information about the recipient, so it is impossible to determine whether interworking is necessary and if so, whether interworking should be performed on the originating network or on the receiving network. Therefore, in step 214, it is necessary to send the packet to the Originating SIP / IP core network connected to the CPM Conversation Server, and to recognize the need for interworking at a later stage.

In step 207, it is possible to know which service (target service, target service) should be transmitted to the receiver based on the presence method. The CPM Conversation Server checks to see if this target service is CPM. If the target service is CPM, you do not need to switch the CPM content received through interworking; Originating SIP / IP core network without switching. If the target service is not CPM, content switching is necessary. In step 201, since it has already been verified that interworking is possible in the receiving-side network, switching is possible in both networks. In this case, depending on the service provider policy, it is possible to decide whether to convert from the calling side or the receiving side. If the caller side switches according to the policy, the process proceeds to step 207.

In step 211, it is determined that the received CPM content should be switched on the source network. Therefore, the CPM Conversation Server must indicate that the received CPM content should be sent to the Originating interworking function. For example, when sending a SIP command (e.g., SIP INVITE) for opening a CPM session, the command "<SIP command> <Request-URI> SIP / 2.0> is included. Here, the Request-URI indicates where the SIP command can be handled and the "SIP / 2.0" is the SIP version. When the originating CPM client sends these commands, it sends a "SIP command <recipient address> SIP / 2.0". Instead, if the CPM conversion server needs to deliver to the Originating interworking function (Orig. IWF) IWF address> SIP / 2.0 ". In the iFC table described by the service provider in the initial filter criteria, Orig. Suppose you have an entry to pass to the IWF. E.g,

CASE method = "INVITE" AND header = "Accept-Contact" = "g.oma.cpm-iw"

THEN: ROUTE request to the specified Originating IWF Terminating Port Address

As described above, if the originating CPM conversation server changes the "Accept-Contact" header to "g.oma.cpm-iw" and sends it, the CPM content will be sent to the originating IWF because it meets the iFC standard.

In step 213, the CPM content server delivers the CPM content received from the CPM conversation server to the originating SIP / IP core network.

The additional operation will be described below. The operation described above is an operation for judging the necessity of interworking, and when it is determined to be necessary, it is set to be transmitted to the interworking function in the source network. This part can be called an interworking decision function. However, if additional interworking is required, it should be determined that it is best to switch content to a non-CPM service (SMS, MMS, IMPS, etc.) format. This part can be called the interworking selection function. The interworking selection function can be performed by various elements (CPM conversation server, interworking function, etc.), but when the CPM conversation server carries out, the following additional operation is required.

Even if it is confirmed in step 201 that there is no receiving side network and CPM SLA, the CPM conversation server searches for the target service of the receiver by using the presence method. If the target service of the receiver is known, the flow advances to step 209. If not, it is not possible to make a decision on the interworking selection, so the flow goes to the existing step 211 described above.

In step 209, the target service indication, i.e., the target service of the receiver, is included in the CPM content. Later, the interworking function can see this indication and switch CPM content to the targeted service.

In steps 207 to 209, when the CPM SLA is present and the target service of the receiver can be known using the presence method, the target service indication can likewise be included in the CPM content.

Here, if the target service of the receiver is not known in step 205, it means that mainly the source network does not support / use the presence method in the beginning, or the contents of the receiver target service can not be obtained even though the presence method is used (For example, the recipient does not allow viewing the target service), the CPM content may include an indication that the target service is not found even if the target service is not found. In this case, this indication also appears between step 202 and step 207 and between step 203 and step 209. (For example, "Target service not found".) If the caller interworking function later receives this indication, And does not use the presence method again to find the target service.

In the above-mentioned operation, it is mentioned that the receiver's target service can be obtained by using the presence method. However, even if the presence method is not used, the target service indication can be included in the CPM content regardless of any other method of knowing the target service.

The following describes the operation of the Originating SIP / IP core network.

The originating SIP / IP core network that inherited the CPM content performs as in FIG. In step 301, the header of the CPM content is compared with the iFC table described above to find out whether there is a suitable criterion (the criterion corresponding to the entity that sent the CPM content is not the review target). If the correct criterion is found, the process proceeds to step 303, The process proceeds to step 305.

In step 303, when a criterion matching the CPM content is found in the iFC table, the reference is transferred to the application server corresponding thereto and the operation is terminated.

In step 305, if a criterion matching the CPM content can not be found in the iFC table, it is confirmed whether the Request-URI (see Request-URI description: description of step 207) in the CPM content is a SIP address (SIP URI). If the address is a SIP address, the process goes to step 311. If it is not a SIP address (e.g., TEL URI), the process goes to step 307.

In step 307, if it is not a SIP address, it is impossible to transfer to the receiving side via the network provided by the SIP / IP core network. Therefore, an entity called ENUM / DNS is connected to find out whether there is a SIP address mapped to this address. If the SIP address to be mapped is found, the process goes to step 311. If there is no corresponding SIP address, the flow goes to step 309.

In step 309, since this step has been confirmed that the receiver has no SIP address, it can no longer deliver the CPM content over the network provided by the SIP / IP core network. The SIP / IP core network delivers the CPM content and terminates the operation so that the Originating interworking function can switch this content.

In step 311, the CPM content can be delivered through the network provided by the SIP / IP core network since it has been confirmed that the recipient has a SIP address when this step is reached. And transmits it to the route corresponding to the SIP address. If the recipient is on another network, it is forwarded to that network. It should be noted that when the CPM Conversation Server changes the Request-URI to the Originating interworking function address as described in step 207, the SIP / IP core network is then transferred to the Originating IWF.

Hereinafter, the operation of the Originating interworking function will be described.

Step 401: Review CPM content for a target service indication that indicates what the recipient's target service is. The process proceeds to step 405, and if not, the process proceeds to step 403.

Step 403: Since there is no target service indication, it is checked whether a target service can be searched through a method capable of interworking function (presence, XDMS, etc.). If the target service is found through this method, the process proceeds to step 409, and if not, the process proceeds to step 405.

Step 405: The interworking function confirms the value of the target service indication. If the display value is something like "Not found", it means that the CPM Conversation Server tried to find the target service through the available methods (Presence, XDMS, etc.) but could not find it. Therefore, the interworking function again directly proceeds to step 407 without using redundant methods (Presence, XDMS, etc.). If the Indication value is not a value of "Not found" but a value indicating a service (e.g., SMS), the process proceeds to step 409.

Step 407: Since the target service is not known in the same way as Presence or XDMS, the interworking function sets itself the target service through the value of the Content-Type field in the CPM content. For example, you could set the "Content-type: application / text" target service to SMS and set the "Content-type: application / image" target service to MMS.

How to configure the target service may vary depending on the service provider's policy. After setting the target service, the process moves to step 409.

In step 409, the CPM content is switched according to the target service format received or set up, and the process proceeds to step 411.

In step 411, the converted content is delivered to the corresponding non-CPM service (service corresponding to the target service display value) and the operation is completed.

The following describes the operation of the terminating SIP / IP core network.

Assume that the CPM content is delivered to the recipient network (terminating SIP / IP core network) following the above Originating interworking function operation. Operation to the terminating SIP / IP core network is the same as the Originating SIP / IP operation described in FIG. However, some points to note are as follows.

In step 301 and step 303, when the CPM content is compared with the iFC and the corresponding criteria are found, the terminating SIP / IP core network is forwarded to the application server meeting the criteria. Here, the "application server" may be a terminating CPM conversation server when CPM is supported, but it may also be a terminating interworking function depending on how the service provider sets the iFC table. For example, if the recipient does not use CPM but uses a different SIP service (PoC, SIMPLE IM, ...) then the CPM content can be passed first to the CPM Conversation Server and then to the IWF if it is not the CPM user , Or directly from the SIP / IP core network to the IWF without the hassle of a CPM Conversation Server.

In step 305, if there is no corresponding criterion through iFC, the terminating SIP / IP core network determines that the Request-URI is a SIP address. Since terminating SIP / IP core network received this CPM content from the originating SIP / IP core network , Terminating SIP / IP core network, it must be a SIP address. Therefore, step 305 always proceeds to step 311, and step 307 and step 309 do not apply in the receiving network.

In step 311, the packet is delivered to the route corresponding to the SIP address. If the SIP address is the address of the receiver, the packet is directly transmitted to the receiver. However, if it is forwarded to the receiving terminal immediately without going through the receiving server or the IWF in advance, the receiving terminal may not understand the CPM contents, and the error message is returned to the calling network. In this case, the error message is forwarded to the originating network, and the originating CPM Conversation Server confirming it can send an error message to the originator, but can also forward the CPM content to the originating IWF at the originator. Following

Hereinafter, the operation of the terminating CPM conversation server will be described. If the operation is subsequently transferred to the terminating CPM conversation server, the operation is as shown in FIG. 5 below. The terminating CPM conversation server operation looks similar to the originating CPM conversation server described in FIG. 2, but has the following differences.

For an Originating CPM Conversation Server, the SLA described in Step 201 can be used to determine whether the receiving network is supplying CPM, and it is not necessary to use an SLA because it already knows that CPM is provided to the terminating CPM Conversation Server .

In step 253, in the case of the originating CPM conversation server, the presence information described in step 203 is used to find out what services the recipient can use and in particular which service he or she wants to receive the CPM content. However, the presence method is used by other servers that are not directly related to other users or recipients, when they want to know the recipient's information. If the originating or receiving network does not support the presence method, or if the recipient decides not to show his presence information, that information is not acceptable. However, in the case of a terminating CPM Conversation Server, it is a server that supports the CPM service directly to the recipient and must know the recipient's preference and service capabilities. Therefore, it accesses the XML document management server described earlier than the presence method, receives information about the receiver, and finds the target service of the receiver.

Steps 259 and 261 are the same as steps 303 and 305 described in Fig. However, since it is performed in the receiving-side network, the terminating interworking function is set as the next hop entity in step 259, and the terminating SIP / IP core network is sent in step 261. An example of a method of setting by the terminating interworking function is the same as that described in step 207.

The additional operation will be described below.

In step 257, when the recipient CPM conversation server performs the interworking decision function as well as the interworking selection function, the CPM content includes an indication of the target service, as described in the source CPM conversation server operation. This indication allows the recipient interworking function to switch CPM content to the target service.

Hereinafter, the operation of the terminating SIP / IP core network after receiving the terminating conversation server will be described.

The operation of the terminating SIP / IP core network which inherited the CPM contents is the same as the operation described in FIG. However, some points to note are as follows.

Since the content received from the terminating conversation server in step 301, the criterion corresponding to the terminating conversation server is not subject to review (i.e., the content is not sent back to the terminating conversation server)

In step 303, a criterion for the terminating interworking function can be found in step 301 according to how the service provider sets the iFC (see description in step 207). In this case, it may be transmitted to the terminating interworking function in step 303.

In step 305, the CPM content is received through the network supporting the SIP, and the Request-URI is only the SIP address. Therefore, steps 307 and 309 are not applied.

In step 311, the entity that can be delivered at this point is the receiving terminal or terminating interworking function. In step 259, when the CPM conversation server transfers the SIP address to the terminating interworking function, the CPM conversation server delivers the SIP address to the terminating interworking function, or otherwise delivers the SIP address to the receiving terminal according to the previously displayed SIP address.

Finally, the operation of Terminating interworking function is explained. When the CPM content is delivered to the Terminating interworking function, the operation is the same as the operation of the Originating interworking function described above.

to the next Interworking  An application example of the scenario will be described.

Below we can see how the system described above works around several scenarios. Let's look at each of the following scenarios.

1. Scenario where the receiving network does not support SIP / SIP, but does not provide CPM service.

2. Scenarios where the receiving network can supply the CPM service, receive recipient information in the presence method, and the recipient is not a CPM subscriber.

3. Scenarios in which the CPM service is provided in the receiving network, but not in the presence method, and the recipient is not a CPM subscriber. In this case, the subscriber can be divided into two sub-cases.

A. If the recipient is a Non-CPM & Non-SIP service subscriber (such as an SMS user)

B. If the recipient is a non-CPM & SIP service subscriber (eg PoC, SIMPLE IM user)

4. Scenarios where the receiving network can not provide CPM services, receive recipient information by presence method, and the recipient is a CPM subscriber, but wants to receive CPM content with other non-CPM services.

5. Scenario where the recipient network supplies the CPM service and the recipient is a CPM subscriber and wants to receive CPM content as a generic CPM service.

Here, the corresponding scenarios are explained through the following flows. The numbers indicated in each flow refer to the operation IDs associated with this flow among the operations described above. For example, "CPM (207, 209)" means that this flow is performed through steps 207 and 209 during the operation of the originating CPM conversation server.

The first scenario is as follows in the case where the receiving side network does not support SIP or SIP, but does not supply the CPM service.

501-503: CPM content is delivered to CPM server A

505-507: CPM Server A confirms that the receiving network does not support CPM through the SLA, sets the next forwarding entity to IWF A and sends it to SIP / IP Core Network A. If the CPM server A also performs the interworking selection function, the target service indication of the receiver is also included in the CPM content.

509-511: SIP / IP Core Network A passes to iWF A according to the SIP URI indicated by the CPM server in the iFC or Request-URI.

513-515: IWF A converts the CPM content into non-CPM content and delivers it to the receiving terminal B. If the target service indication of the recipient is included in the CPM content, switch it according to the service format. If there is no indication of the target service, the interworking function can provide information to know the target service directly (eg, presence, XDMS, Content- Type) and converts the CPM content according to the target service.

In the second scenario, the CPM service is provided in the receiving-side network, the receiver information can be received by the presence method, and the following is the flow when the receiver is not a CPM subscriber.

601-603: CPM content is delivered to CPM server A

605-607: CPM Server A has verified that the receiving network does not support CPM through the SLA, but it also uses the presence information to verify that the recipient's target service is not CPM (that is, CPM content must be switched) And then sends it to SIP / IP core network A. If the CPM server A also performs the interworking selection function, the target service indication of the receiver is also included in the CPM contents.

609-611: SIP / IP Core Network A delivers to iWF A according to the SIP URI indicated by the CPM server in the iFC or Request-URI.

613-615: IWF A converts the CPM content into non-CPM content and delivers it to the receiving terminal B. If the target service indication of the recipient is included in the CPM content, switch it according to the service format. If there is no indication of the target service, the interworking function can provide information to know the target service directly (eg, presence, XDMS, Content- Type) and converts the CPM content according to the target service.

The third scenario is a flow in which the CPM service is provided in the receiving-side network, but the receiver information can not be received by the presence method, and the receiver is not a CPM subscriber. This case can be divided into two sub-cases.

A. If the recipient is a Non-CPM & Non-SIP service subscriber (such as an SMS user)

B. If the recipient is a non-CPM & SIP service subscriber (eg PoC, SIMPLE IM user

For non-CPM & Non-SIP service subscribers (eg SMS users), the following flow is performed. The flow description is as follows.

701-703: CPM content is delivered to CPM server A

705-707: CPM Server A verifies that the receiving network does not support CPM through the SLA, but can not verify the target service of the recipient through the presence information. (Ie, it is not known whether or not the CPM content should be switched). Therefore, regarding the interworking-related operation, the received CPM content is sent to the SIP / IP core network A. If CPM server A also performs the interworking selection function and can not use the presence method but can not obtain the target service of the recipient, the indication "Target service not found" is included in the CPM content.

709-711: SIP / IP Core Network A can not find a standard for iFC, and because the address in the Request-URI field is not a SIP address, it attempts to connect to ENUM / DNS and request a SIP address that matches this address , The SIP address is not received. Therefore, the receiver knows that it is not a SIP user and can not forward it to the SIP network. Therefore, CPM content is delivered to IWF A to convert CPM content.

713-715: IWF A converts the CPM content into non-CPM content and delivers it to receiving terminal B. If the target service indication of the recipient is included in the CPM content, switch it according to the service format. If there is no indication of the target service, the interworking function can provide information to know the target service directly (eg, presence, XDMS, Content- Type) and converts the CPM content according to the target service.

For the following non-CPM & SIP service subscribers (eg PoC, SIMPLE IM users) the following flow is performed.

801-803: CPM content is delivered to CPM server A.

805-807: CPM Server A verifies that the receiving network does not support CPM through the SLA, but can not verify the recipient's target service through presence information (ie, it can not tell if CPM content should be switched). Therefore, regarding the interworking-related operation, the received CPM contents are sent to the SIP / IP core network A. If the CPM server A also performs the interworking selection function and can not use the presence method but can not obtain the target service of the recipient, the indication "Target service not found" is included in the CPM content.

809-811: SIP / IP Core Network A can not find a standard for iFC, but the address in the Request-URI field will be able to connect to the SIP address or ENUM / DNS to receive a SIP address that matches this address . Therefore, the receiver knows that it is a SIP user and can forward it to the SIP network. Thus, the CPM content is delivered to the SIP / IP core network B.

813-815: SIP / IP Core Network B can find criteria that match IWF B as the service provider establishes the iFC table. In this case, the SIP / IP core network B delivers CPM content to IWF B.

817-819: IWF B converts the CPM contents into non-CPM contents and delivers them to the receiving terminal B. If the target service indication of the recipient is included in the CPM content, switch it according to the service format. If there is no indication of the target service, the interworking function may transmit the information for knowing the target service directly (eg, presence, XDMS, Content- Type) and converts the CPM content according to the target service.

Explanation of Alternative Flow 1 is as follows.

813b-815b indicates that the service provider does not set a criterion to be transmitted to the IWF B in the iFC table as in the above step 7-8, and can not find a criterion for another match. The SIP / IP core network B confirms the address in the Request-URI and immediately delivers the CPM content to the receiving terminal B.

If the receiving terminal B does not receive the CPM contents received by the receiving terminal B 817b-825b, an error message is sent and the message is transmitted to the calling terminal.

Explanation of Alternative Flow 2 is as follows.

When the CPM Server A receives the error message described in 9b-11b, it knows that the CPM content needs to be switched, and can set the CPM Server A to deliver the CPM content to the IWF A. This process is the same as in Scenario 1 4-8.

The fourth scenario is as follows when the CPM service is provided in the receiving-side network, the receiver can not receive the receiver information by the presence method, and the receiver desires to receive the CPM content with the other non-CPM service although it is the CPM subscriber.

901-903: same as the flow described in Scenario 3b above.

913-915: SIP / IP core network B confirms iFC and delivers CPM content to CPM server B.

917-919: CPM Server B has reviewed CPM content and information about recipients (eg user preferences) stored on the XDM server, and wants to receive this CPM content via a message service other than CPM (e.g. SMS). . Therefore, the content is set to be forwarded to IWF B and sent back to SIP / IP core network B. If the CPM server B also performs the interworking selection function, the target service indication of the receiver is also included in the CPM content.

921-923: SIP / IP core network B delivers to iWF B according to the SIP URI indicated by CPM server B in iFC or Request-URI.

925-927: IWF B converts the CPM contents into non-CPM contents and delivers them to the receiving terminal B. If the target service indication of the recipient is included in the CPM content, switch it according to the service format. If there is no indication of the target service, the interworking function can provide information to know the target service directly (eg, presence, XDMS, Content- Type) and converts the CPM content according to the target service.

The last scenario is a flow where the recipient is a CPM subscriber and wants to receive CPM content as a generic CPM service.

1001-1015: same as the flow described in Scenario 4 above.

1017-1019: CPM Server B examines the CPM content and information about the recipient (e.g., user preference) stored in the XDM server, and confirms that the CPM service wants to receive the CPM content. Therefore, regarding the interworking-related operation, the received CPM contents are sent to the SIP / IP core network B without change.

1021-1023: The SIP / IP core network B follows the general procedure and delivers it to the receiving CPM terminal according to the SIP URI indicated in the Request-URI.

1 is a diagram showing a configuration of a general CPM system;

2 illustrates an operation of a CPM server according to an embodiment of the present invention;

3 is a diagram illustrating operation of a SIP / IP core network according to an embodiment of the present invention;

4 is a diagram illustrating an operation of an interworking function according to an embodiment of the present invention;

5 illustrates an operation of a CPM server according to an embodiment of the present invention;

6 to 11 are diagrams illustrating scenarios according to an embodiment of the present invention.

Claims (7)

A method for interworking a Converged iP Messaging service (CPM) Conversation Server in a Unified Messaging service, The method comprising the steps of: determining whether a CPM service is supported by a receiver terminal to receive the CPM content from the sender terminal; Confirming a supportable service in the recipient terminal when the recipient terminal does not support the CPM service; And displaying the confirmed supportable service, and transmitting the CPM content. The method according to claim 1, The process of confirming the service includes: Confirming whether a service level parameter is set between the receiver terminal and the transmitter terminal, and checking whether the receiver terminal supports the CPM service. The method according to claim 1, The service that can be supported by the receiver terminal includes: Wherein at least one of at least one of whether or not to allow interworking by a user, at least one type of messaging service to be used in interworking, and a priority of each messaging service to be used in interworking is determined. In an interworking method of a SIP / IP core network in a unified messaging service, Receiving a request for confirming a service supported by a recipient terminal of the CPM content; Confirming to which server the CPM content can be delivered based on an initial filter criterion (iFC) If the server to which the CPM content is to be delivered is not confirmed, confirming a SIP (Session Initiation Protocol) URI matched with the address of the recipient; And transmitting the CPM content to the path of the identified SIP URI. 5. The method of claim 4, And transmitting the CPM content to a sender terminal of the content if the SIP URI is not verified as a result of confirming a SIP URI matched with the recipient's address. 5. The method of claim 4, Converting the CPM content according to a format of the target service if the CPM content includes a target service indication indicating a target service of the receiver; And delivering the converted CPM content to a service corresponding to the target service. 5. The method of claim 4, Confirming a service that can be supported by the CPM content server that has delivered the CPM content if the CPM content does not include a target service indication indicating a target service of the receiver; And setting an interworking method to a service that is different from the service that can be supported.

Images