Method and system for guaranteeing seamless session when replacing poc terminal in poc system

The present invention allows a PoC terminal in a PoC system to change a PoC terminal without loss of media stream for an ongoing PoC group session when the PoC (Push to talk over Cellular) terminal is replaced for a specific purpose. Regarding the session sustainability guarantee method and system at the time of replacement.

With the epoch-making development of mobile communication and the expansion of mobile communication networks, various additional services and applications using mobile phones are being provided. Moreover, the demands of mobile phone users have also diversified, and have expanded from simple calling services to location services, multimedia services, PTT (Push to Talk) services, and so on. In particular, the PTT service supports various additional functions such as instant messenger and status display, as well as group calls and voice calls provided by conventional radios (Existing Radio System) and TRS (Trunk Radio System).

Currently, the establishment of standards for PoC (Push-to-talk over cellular: hereinafter referred to as PoC) services that introduce such PTT functions into mobile communication networks and provide services is being actively discussed. One of the features of the PoC service is that users can participate in multiple PoC sessions and can talk while moving between PoC sessions as needed. The requirement that users must be able to make calls while moving through multiple PoC sessions is specified in the OMA (Open Mobile Alliance), the organization that defines mobile communication services.

The structure of a general PoC service system will be described with reference to the conceptual diagram of FIG. Referring to FIG. 1, the PoC client 10 is a service requester provided in the mobile terminal, and is a SIP / that supports SIP (Session Initiation Protocol) and IP (Internet Protocol) multimedia functions via the access network 20. It is connected to the IP core network 30.

The PoC client 10 resides on the PoC user terminal to provide a connection to the PoC service. PoC client 10 creates a PoC session, joins the session currently in progress, and ends the session. Otherwise, the PoC client 10 forms and propagates a talk burst, supports Instant Personal alerts, and authenticates when connecting to the PoC service. Unless otherwise stated below, PoC users and PoC clients 10 are considered the same as PTT service subscribers.

The SIP / IP core network 30 is linked with the PoC server 60, the GLMS (Group List and Management System) 50, and the presence server 70 to support the PoC service.

In general, the standard for SIP is defined in the IETF (Internet Engineering Task Force) RFC (Request for Comments) 2543 document. SIP is an application hierarchy control protocol for setting, modifying, and terminating sessions and calls for multimedia communications such as video and audio. SIP is a protocol that exists on the UDP (User Datagram Protocol) / TCP / IP hierarchy, and is a client / server protocol that can send and receive SIP request / response messages in a request / response method. Supports all Unicast and Multicast sessions to start a session by (invite).

The SIP request message provides six functions in RFC2543 as follows. INVITE (session join invitation), ACK (acceptance of invitation request), BYE (end call), REGISTER (user agent registers with redirect server database), CANCEL (waiting request cancellation), OPTIONS functions. SIP response messages have status codes such as 1xx (information response), 2xx (successful response), 3xx (redirection response), 4xx (client error, request failure), 5xx (server failure), 6xx (global failure). provide.

The PoC server 60 is a Controlling PoC Function (CF) that maintains and manages a PoC session, or a Participating PoC Function (PF) for participating in a PoC session for one-to-one PoC calls or one-to-many calls (or group calls). To support.

Hereinafter, the functional blocks of the PoC server will be described with reference to the conceptual diagram of FIG.

The PoC server is divided into a Controlling PoC Function that maintains and manages PoC sessions in general and a Participating PoC Function that is in charge of maintenance and management between each PoC session, and is explained in detail with reference to the table below. To do.

<tables num="1"><img file="JP4795366B2_D0001.tif" /></tables>

As shown in Table 1 above, CF is responsible for maintaining and managing PoC sessions as a whole. The PoC server receives the PoC client's floor request, orders the clients, and grants authority. In addition, the PoC server distributes the Talk Burst requested by any PoC client to all other PoC clients that participated in the group PoC call, and provides information on the PoC client that participated in the group PoC call.

As can be seen from Table 2 below, the PF manages the PoC session between the CF and each PoC client. In particular, the PF serves to relay the voice between the CF and the PoC client when the PoC client requests a voice or the CF grants the client a voice. The PF also relays media between the CF and the client, transcoding the CF and the PoC client if they use different codecs, and one PoC session for simultaneous sessions. Performs the role of filtering.

<tables num="2"><img file="JP4795366B2_D0002.tif" /></tables>

As mentioned above, in the PoC service system, the PoC user can enter information about the group and group members into the GLMS50 via his PoC terminal and call himself through the individual or group list transmitted from the GLMS50. You can see information about PoC users who can. Optionally, the PoC service provider can modify and manage information about the group and group members in the GLMS50 by entering the information via a trusted network such as the Internet or an intranet.

In order to use the PoC calling service, the PoC user registers his / her PoC address in the SIP / IP core network 30. The SIP / IP core network 30 stores information about PoC users at the request of PoC users. Therefore, when another PoC user wants to request a PoC group call, as described above, his / her information is registered in the SIP / IP core network 30 and the group identification information transferred from the GLMS 50 is used. Request a group PoC call from your SIP / IP core network 30. At this time, the SIP / IP core network 30 executes the address determination and domain position determination processes using the PoC user information requesting the call, and makes a PoC call to the home PoC server 60 in which the PoC user requesting the call is registered. Communicate your request. In response to this PoC call request, the PoC server 60 prepares to open a PoC session, acquires each user information from the GLMS50 server, and then transmits the PoC call request signal to the corresponding SIP / IP core network 30. At this time, in the case of a PoC call request to a user in the intra domain, the PoC server 60 executes both the PF and CF functions. The PoC server 60 that manages the PoC user who has been requested to make a call requests the PoC user to make a PoC call after executing the positioning process of the SIP / IP core network 30 using the information of the PoC user transmitted to him / her. ..

FIG. 3 is a conceptual diagram for explaining the CF block and the PF block of the PoC server.

Referring to FIG. 3, PoC clients 111, 121, 131, 141 connect to CF100 via PF110, 120, 130, 140 to open a PoC session. Here, when the right to speak is given to the requester who has been permitted by CF100, the media based on the statement of the corresponding PoC client is transmitted to each PoC client.

First, in order to detail the session connection procedure for the PoC client in the terminal, the following features for the PoC system defined in OMA will be described. The PoC system with the settings of the PoC session sender and receiver in OMA has the following features.

PoC systems can be divided into two types, on-demand session mode and pre-established session mode, depending on whether or not the connection with the PoC server in the user's home network can be set.

Pre-established session mode means that a PoC user sets up a specific session between a PoC client and a PoC server 600 belonging to his home network at his request. The pre-established session allows PoC users to negotiate media parameters they use with PoC Server 60 and quickly set up calls without having to renegotiate media parameters between the server and client used. It is necessary to make it. To set up a pre-session, the PoC client uses the SIP INVITE method to make the body part (SDP (Session Description) Provide the supported media parameters to Protocol) body) and respond to the media parameters provided by the server. The PoC client replies to the PoC user with the newly set pre-session identification information in the response message, including the conference URI. When using such a pre-session, it is possible to pre-configure the IP address, port number, codec used, talk burst control protocol, and the like.

On-demand session mode means that the PoC call concatenation procedure is executed after the PoC user has not set up a pre-session and has received an INVITE message from another PoC user.

On the other hand, the PoC system enables half-duplex group PoC calls including the above features. Such a one-to-many conference function is a typical feature of a PoC system, depending on the characteristics of the set group, such as an ad hoc PoC group, a pre-arranged PoC group, and a chat PoC. Divided into groups (chat PoC group).

In a PoC system with the above characteristics, each element such as PoC client, PoC server and SIP / IP core network, group list server, presence server, and initial PoC session start and connection procedure through signaling between them. Is disclosed in the OMA standard document (Draft) as a conventional technology based on SIP, and its description is omitted.

On the other hand, in a conventional PoC system having the above-mentioned characteristics, a situation may occur in which a PoC client participating in an ongoing PoC session is to be replaced.

As a typical example of the situation, in the first example, the PoC session currently participating has the characteristic of a session that supports only audio, but media such as video is exchanged in addition to audio as the call progresses. There is a need. In this case, some PoC users who use only voice support terminals will have to replace their PoC clients with video support terminals.

The second example is when the currently used terminal is almost exhausted but is currently trying to join without ending the PoC session.

The third example is when a user is attending a PoC session using a fixed PoC terminal (eg, a VoIP terminal) in his office but feels the need to move. In such a case, it is necessary to use your own mobile wireless terminal (mobile PoC terminal) to connect the sessions you are currently participating in.

In addition to the above example, there may be many cases where the PoC terminal needs to be replaced due to the special request of the user.

For such requirements, the conventional PoC session replacement process based on the OMA PoC1 standard technology will be described with reference to the flowchart of FIG.

In FIG. 4, the PoC client A1 (111) is a terminal that has already participated in the ongoing session, and attempts to participate in the ongoing session by using the PoC client A2 (112) at the request of the user. It shows the process.

First, PoC client A1 (111) transmits a SIP BYE message to PFA (110) on the home network to which it belongs to end the participating PoC session (step S101), and PFA (110). Transmits the BYE message to CF (100) through the information about the SIP address contained in the BYE message (step S102).

The CF (100) then releases the PoC client A1 (111) by transmitting a 200 OK response signal to end the PoC conference (step S111, step S112) after receiving the session BYE message. Media transmission will be stopped.

On the other hand, the PoC user who has terminated the session transmits an INVITE message to PFA (110) through PoC client A2 (112) in order to rejoin the previous session using the new PoC client (step S121). The INVITE message is transmitted via PFA (110) to CF (100), which controls the ongoing conference session (step S122). At this time, the PoC client A2 (112) needs to have unique identifier information (session ID) regarding the PoC session in order to rejoin the ongoing PoC session.

The CF (100) then joins the new PoC client A2 (112) into the session by transmitting a 200 OK response (step S131, step S132) and receives the ACK signal (step S141, step S132). S142), confirm the session participation. At the same time, the CF (100) transmits the relevant floor message to the PoC client A2 (112) with the right to speak in the current session. When another PoC client transmits media, CF (100) uses RTCP (Real-Time Transfer Control Protocol) to transmit a Floor Taken message to PoC client A2 (112) (step S151, step S152).

After that, when the sessions are connected, the media is transmitted to the PoC client A2 (112) using RTP (Real-Time Transfer Protocol).

The conventional process as described above has the following problems.

First, PoC users must have a PoC session identifier to rejoin the same PoC conference session that they joined on PoC client A1 using PoC client A2. However, an arbitrarily generated PoC session identifier, such as an ad hoc session, must be transmitted to PoC client A2 at the user's passive input.

Also, PoC client A2 cannot use the SIP session dialog information previously used by PoC client A1. Therefore, it is impossible to receive the media stream transmission using the session dialog that has already been used.

Therefore, while the PoC client A2 switches PoC client terminals, the media stream of the PoC session cannot be transmitted, which reduces the user experience (QoE: Quality of Experience).

<p> An object of the present invention is to transmit only the PoC terminal without loss of the ongoing media stream by transmitting the address information and session identifier information of the PoC terminal to be replaced before the end of the session to the server or PoC client. It is an object of the present invention to provide a session sustainability guarantee method and its system at the time of PoC terminal replacement in a PoC system that can be replaced.</p>

<p> The session sustainability guarantee method at the time of PoC terminal replacement in the PoC system according to one aspect of the present invention sends a terminal replacement request message for the PoC client to replace the PoC terminal while sustaining the session to the session management server. A step, a step in which the session management server receives the replacement request message and sends an INVITE message to the replaced PoC client, and a step in which the terminal replacement target PoC client receives the INVITE message and through the current session. Includes steps to receive media.</p><p> The session sustainability guarantee method at the time of PoC terminal replacement in the PoC system according to another aspect of the present invention is a PoC for the PoC client to replace the terminal replacement request message for replacing the PoC terminal while maintaining the session. The step of sending to the client, the step of the terminal replacement target PoC client receiving the terminal replacement request message and sending the INVITE message including the current session information to the session management server, and the step of receiving the INVITE message. The session management server includes a step of transmitting media to a PoC client to be replaced.</p><p> The PoC system for guaranteeing the session sustainability at the time of PoC terminal replacement according to another aspect of the present invention includes a terminal replacement request PoC client that requests a PoC terminal replacement and a terminal replacement target PoC client that is a PoC terminal replacement target. , Receives the terminal replacement request message from the terminal replacement request PoC client, refers to the terminal replacement target PoC client information included in the terminal replacement request message, and sends an INVITE message to the terminal replacement target PoC client. Includes a session management server that maintains the session and transmits media to the terminal replacement target PoC client.</p><p> The PoC system for session sustainability guarantee at the time of PoC terminal replacement according to another aspect of the present invention receives a terminal replacement request PoC client requesting a PoC terminal replacement and a terminal replacement request message from the terminal replacement request PoC client. Then, the terminal replacement target PoC client that refers to the current session information and sends an INVITE message including the current session information, and the terminal replacement target that receives the INVITE message and maintains the current session. Includes a session management server that transmits media to PoC clients.</p><p> According to yet another aspect of the present invention, a terminal replacement request message containing information for a PoC terminal to be replaced with a session identifier is transmitted to a session management server, and when the session management server completes the terminal replacement process, A PoC system that receives a session end message for session end and provides a PoC terminal that sustains the session when the terminal is replaced.</p><p> According to the present invention and another aspect, a session management server directly transmits a terminal replacement request message including a session identifier and information on the replaced PoC terminal to the replacement target PoC terminal via the SIP / SIP core network. A PoC system that receives a session end message to end a session from provides a PoC terminal for sustaining a session when the PoC terminal is replaced.</p><p> According to yet another aspect of the present invention, a terminal replacement request message is received from the replacement request PoC terminal, and an INVITE message is transmitted to the session management server according to the current session information received from the replacement request PoC terminal. A PoC system that receives media from the session management server provides a PoC terminal that sustains a session when the PoC terminal is replaced.</p>

<p> According to the present invention, instead of the procedure of further executing session concatenation after the end of the session, the desired PoC client is concatenated to the PoC session instead of the current client according to the instruction of the PoC client.</p><p> Therefore, by preventing discontinuous media transmission, it is possible to provide improved services to PoC users.</p><p> In addition, a PoC compatible client (PoC compliant client) that can connect a PoC session to a PoC session that is currently in a call can be used to switch the PoC client that is currently in a call, and the process proceeds when the PoC client is replaced. It is possible to prevent the loss of the transmission media stream of the PoC session inside.</p><p> This enables continuous calls by the user in situations where the PoC terminal needs to be replaced due to media changes or mobility requirements of the PoC user's PoC call. It is also expected to improve user QuE and expand the PoC terminal and service market.</p>

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings so that a person having ordinary knowledge in the field to which the present invention belongs can easily carry out the present invention.

The present invention uses an IMS (IP multimedia CN) network that has been standardized by 3GPP (3rd Generation Partnership Project) and 3GPP2 (3rd Generation Partnership Project 2), and uses half duplex type calls and user groups and presence information. The application service of the PoC system that enables immediate calls by requesting calls will be explained using.

The present invention is constructed on the basis of at least one of the PoC client and PoC server (PF, CF) defined in the OMA PoC Release 1 system, and SIP and SIP extension protocols. The basic configuration is the same as the general PoC (Push-to-talk over Cellular) basic structure shown in Fig. 1, but its description will be omitted.

Figure 5 shows that when a PoC user wants to replace only a terminal without ending the session, when he / she selects the terminal he / she wants to replace, the result information is transmitted to the server side and the terminal is replaced by the server. It is a flowchart which showed the process for changing the PoC compatible terminal during a call by 1st Embodiment of the invention.

As shown in Figure 5, the PoC client A1 (1110) has a pre-session session with the CF (1000), which controls the group session by being linked to the PFA (1100), which is the PoC server of the home network. At this time, the PoC client A1 (1110) stores the PoC session identifier (PoC Session Identity) received through the session participation, and also with the PoC client A1 acquired through the INVITE message and the 200 OK response message to the INVITE message. Stores the specified session dialog information (dialog identifier) with the PoC server.

The dialog identifier is a global identifier, and is composed of a From tag, a To tag, and a Call-ID of the SIP INVITE message.

The PoC client A1 (1110) storing the above information generates a SIP REFER message and then transmits the SIP REFER message to the PoC server that manages the session, that is, CF (1000) (step S1001, step S1002). Here, the PoC client A1 (1110) sets the unique identifier of the PoC session (generally CF-managed Conference URI: conf_uri_cfx) to the Request URI of the REFER message when transmitting the SIP REFER message, and the user Set the address information of the PoC client that is going to be used in the Refer-To header information.

FIG. 6 is a diagram showing the REFER message format used in the process of FIG. As shown in Figure 6, the Refer-To header field (P3) contains the appropriate SIP method methods to take with the destination address information.

In the present invention, the INVITE message is transmitted when the session is opened. The INVITE message information will be described after being described with respect to the REFER message information.

The address information of the target terminal (terminal to be changed) contained in the Refer-To header field (P3) can be the SIP URI currently used by PoC client A1 or another SIP URI.

If you use the same SIP URI, the ability of PoC Client A2's SIP User Agent to distinguish between the PoC Client A2 (1120) you are trying to change and the current PoC Client A1 (1110). Propagate a new SIP message to PoC client A2 (1120) with information on the preference of the SIP user agent that matches (characteristic value: mobile or video or explicit, etc.).

On the other hand, the REFER message is session connection information (session dialog identifier) that enables continuous reception of the contents of the PoC session currently in progress using the target PoC client A2 (1120) (From of P2 in FIG. 6). -tag, To-tag and call-ID) and target terminal information (refer-to on P3 of FIG. 6) are included.

The PoC server CF (1000) that has acquired the REFER message responds with an Accepted message in order to reply with successful SIP processing (step S1101, step S1102).

After that, the CF transmits an INVITE message to the address information of the SIP URI (conf_uri_cfx in P1 of FIG. 6) received through the REFER message (step S1201, step S1202).

FIG. 7 is a diagram showing the INVITE message format used in the process of FIG.

As shown in Figure 7, the INVITE message contains User Agent preference information (Q3 in Figure 7) set by the user's request to PoC Client A2 (1120). Communicate the session request.

In addition, CF (1000) recognizes an indicator that alternates PoC client A1 (1110) in the same dialog. To this end, CF (1000) replaces the session dialog information (which substitutes for the ongoing session to receive media transmission through the same session dialog) in the Replaces header field of the INVITE message (Q4 in Figure 7). Transmit through.

Next, the INVITE message routed to PFA (1100) by the corresponding address information (SIP URI) (Conf_uri_cfx) is transmitted to the SIP / IP core network, and the SIP / IP core network is SIP REGISTER by PoC client A2 (1120). Corresponding PoC client A2 (1120) according to the client characteristic value of the user agent registered in the message (fixed terminal (Fixed), mobile terminal (Mobile), video providing terminal (video), etc.) and the information contained in the Accept-Contact header field Q3. ).

The PoC client A2 (1120) then replies a 200 OK response to the CF (1000) according to the user's response (steps S1301, S1302). At this time, the newly generated session dialog information (dialog ID generated by the transaction in steps S1201 to S1302) is transmitted to CF (1000). This causes the PoC server CF (1000) to replace the previous dialog with the newly generated dialog and transmit the media.

When the CF (1000) receives the 200 OK response, the CF (1000) that manages the conference returns an ACK signal to the PoC client A2 (1120) (step S1401, step S1402). At the same time, the media transmitted to the PoC session is determined to be transmitted to the newly attached PoC client A2 (1120), and the talk burst control message notifying the decision is transmitted (step S1501, step S1502).

Also, the media stream in the session is transmitted to the new PoC client A2 (1120) after receiving a 200 OK response (step S1600). At this time, the media is transmitted up to PFA (1100) by the same route, and is routed to the corresponding PoC client A2 (1120) via the SIP / IP core network.

On the other hand, the PoC server CF (1000) that received the 200 OK response transmits a BYE message for session termination to PoC client A1 (1110) in order to terminate unnecessary session concatenation (step S1701, step S1702). ), 200

Confirm the end of the session by receiving the OK response (step S1801, step S1802).

Hereinafter, a second embodiment in which the terminal to be replaced takes the lead and the terminal is replaced while maintaining the session will be described.

FIG. 8 is a flowchart showing a process for changing the PoC compatible terminal during a call according to the second embodiment of the present invention.

Figure 8 shows that when a PoC user tries to replace only the terminal without ending the session, the terminal to be replaced can be replaced by the terminal to be replaced by transmitting information about the session currently being maintained to the terminal to be replaced. Shows the process that takes place.

Referring to FIG. 8, in the same situation as in the first embodiment of FIG. 5, PoC client A1 (1110) instructs the session information (Conference URI, dialog ID, etc.) to which it belongs and PoC session replacement. The information to be sent is transmitted to the corresponding client A2 (1120) through the REFER message. At this time, the information contained in the REFER message is similar to the REFER message in FIG. 6, but has the following differences.

After the PoC client A1 (1110) generates a SIP REFER message, the REFER message is transmitted via SIP / IP core network routing to client A2 (1120) wishing to substitute the session (step S2001, step S2002). .. Here, the REFER message is forwarded via a general SIP proxy server, so it may not go through PFA (1100).

To do this, PoC client A1 (1110) sets the unique identifier of the PoC session (typically the Conference URI: Conf_uri_cfx stored in CF) to the Refer-To header field value when generating the SIP REFER message, and the user Sets the address information of the PoC client that is going to be used by the value of the Request URI.

The content of the REFER message will be described with reference to FIG.

The Refer-To header field (R5) contains the appropriate SIP message method to be taken with the destination address information. In the above invention, the SIP message method is specified by the INVITE message to open a session.

In the present invention, the SIP message method is specified by an INVITE message when a session is opened. The INVITE message information will be described after the explanation for the REFER message information.

The address information contained in the Request URI can be the SIP URI currently used by PoC client A1 or another SIP URI.

Similar to the description in FIG. 5, when using the same SIP URI, the PoC client A2 (1120) is used to distinguish between the PoC client A2 (1120) to be replaced and the current PoC client A1 (1110). PoC client A2 with a new SIP invitation message containing information on SIP user agent preferences (characteristic values: mobile, video, explicit, etc.) that match the support capabilities of the SIP user agent. Transmit to (1120). By transmitting the Accept-Contact header field (R4 in FIG. 9) in the new REFER message including the preference information, it can be routed to the PoC client A2 (1120) in the SIP / IP core network.

On the other hand, the REFER message is the session connection information (session dialog identifier) (From-tag, R2 in FIG. 9) so that the currently in-progress PoC session is continuously connected using the PoC client A2 (1120). Includes target terminal information (refer-to in R5 in FIG. 9) that is replaced with (To-tag and call_ID).

The REFER message also includes a MIME (Multipurpose Internet Mail Extensions) body that includes a Referred-By header (R6) and the relevant content to transmit the dialog information being used by the PoC client A1 (1110).

Upon receiving the REFER message, the PoC client A2 (1120) responds with an Accepted message in order to reply to the successful SIP process (step S2101, step S2102).

After that, the PoC client A2 (1120) transmits an INVITE message to the address of the SIP URI (Conference URI of the PoC session) received through the Refer-To header of the REFER message (step S2201, step S2202).

The INVITE message information transmitted at this time will be described with reference to FIG.

As shown in Figure 10, PoC Client A2 (1120) replaces the session dialog used by PoC Client A1 (1110) (transmitting media through the same session dialog for an ongoing session). (Alternate to receive), convey the relevant session dialog information through the Replaces header field (T4 in Figure 10) of the INVITE message.

The PoC server CF (1000) returns a 200 OK response after receiving the session concatenation request from the PoC client A2 (1120) (step S2301, step S2302). At this time, the newly generated session dialog information (dialog ID generated by the transaction in steps S2201 to S2302) is stored in CF (1000) and the RTP media stream transmitted through the conventional dialog is sent to the new dialog. Confirm that it can be transmitted with. PoC client A2 returns an ACK signal in response to the 200 OK response (step S2401, step S2402).

On the other hand, the CF (1000) transmits a 200 OK response and at the same time transmits a talk burst control message notifying the PoC client A2 (1120) of the transmission of the media (step S2501, step S2502). As a result, the media stream is transmitted to the new PoC client A2 (1120) after sending a 200 OK response (step S2600, step S2700). At this time, the media is transmitted to PFA (1100) by the same route, and is routed to the corresponding PoC client A2 (1120) via the route determination of the SIP / IP core network.

Then, after transmitting the 200 OK message, the PoC server CF (1000) transmits a BYE message to end the session to PoC client A1 (1110) to end unnecessary session concatenation (step S2801, Step S2802), confirm the end of the session by receiving a 200 OK response (step S2901, step S2902).

Hereinafter, the messages shown in FIGS. 6, 7, 9 and 10 will be described in detail.

FIG. 6 shows the format of the REFER message used in the flowchart of FIG. 5 when the SIP URIs of PoC client A1 and PoC client A2 are the same.

The Request URI (P1) of the REFER message in Figure 6 is set to the conference URI managed by the CF, and the Refer-To header (P3) value is specified as the SIP URI value of the PoC client A2 where the CF requests the INVITE message. Will be done. At this time, the SIP URI of the Refer-To header field (P3) is transmitted including the preference (characteristic value) of the PoC user in order to distinguish the PoC client using the same SIP URI. Therefore, in the present invention, as shown in FIG. 6, the preference of the PoC session requester (fixed terminal (Fixed), mobile terminal (Mobile), video providing terminal (video), special) is used as the URI parameter of the Refer-To header. Define to add a destination terminal (explicit, etc.).

The PoC client A1 uses the Referred-By header field (P4) to convey the dialog information (dialog ID) to which it is linked. The Referred-By header field (P4) contains the SIP URI information for PoC client A1 and the identifier (CID) for the attached content. The PoC client A1 transmits its own session dialog information through the corresponding MIME body part (P5). Using such content identifiers and dialog information, the PoC server CF can use the same session dialog when transmitting a new INVITE message.

Figure 7 shows the message format when generating an INVITE message after receiving a REFER message. As mentioned above, the client preference information contained in the Refer-To header is used in the Accept-Contact header part (Q3) of the INVITE message to distinguish PoC clients for the same SIP URI and route the INVITE message. To do. On the other hand, the Replaces header (Q4) includes the session dialog information transmitted through the REFER message so that the media for the same session dialog is received when the PoC client is replaced.

Figure 9 shows the format of the REFER message when the SIP URIs of PoC client A1 and PoC client A2 are the same. The Request URI (R1) of the REFER message is set to the SIP URI of the new PoC client A2, and the Refer-To header value (R5) is set to the URI value of the CF in which the PoC client participates.

It also sets the preferred user agent characteristics in the Accept-Contact header (R4) for routing to PoC client A2 using the same SIP URI, and adds the Refer-To header (R5) to the PoC session identifier information. Set the message type that the PoC client A2 needs to transmit to INVITE.

On the other hand, the PoC client A1 uses the Referred-By header field (R6) to convey the dialog information (dialog ID) to which it is linked. The Referred-By header field contains the SIP URI information for PoC client A1 and the identifier (CID) for the attached content so that you can convey your session dialog information. PoC client A2 is new with such content identifier (CID, ie 20398823.2UWQFN309shb3@domain.com) and dialog information (88upf11a@client_apc.domain.com;to-tag=7743;from-tag=6472) The same session dialog can be used when transmitting INVITE messages.

Figure 10 shows the message format when generating an INVITE message after receiving a REFER message. As mentioned above, the PoC client's Capability information contained in the Accept-Contact header is identified from the PoC client A1 using the same SIP URI in the Contact header (T3) of the INVITE message. .. On the other hand, the Replaces header (T4) includes the Referred-By header of the REFER message and the session dialog information transmitted through the MIME body part, and the PoC client A2 uses the same session dialog instead of the PoC client A1. Make sure to receive media.

The present invention is not limited to PoC systems, but uses the IMS (IP multimedia CN) network, which is being standardized by 3GPP and 3GPP2, but has been completed, and uses half-duplex type calls and user presence information to make calls. Applies to all systems where requested calls are opened.

The present invention described above can be variously replaced, modified and modified without departing from the technical idea of the present invention by a person having ordinary knowledge in the field of technology to which the present invention belongs. Therefore, the present invention is not limited to the above-described embodiment and the attached drawings.

<figref num="1">It is a conceptual diagram for demonstrating a general PoC service system.</figref><figref num="2">It is a conceptual diagram which shows the structure of a general PoC server.</figref><figref num="3">It is a conceptual diagram for explaining a CF block and a PF block of a PoC server.</figref><figref num="4">It is a flowchart which shows the general process for PoC session change for replacement of a PoC terminal.</figref><figref num="5">It is a flowchart which shows the process for changing during a call of the PoC compatible terminal by 1st Embodiment of this invention.</figref><figref num="6">It is a figure which shows the REFER message format in the process of FIG.</figref><figref num="7">It is a figure which shows the INVITE message format in the process of FIG.</figref><figref num="8">It is a flowchart which shows the process for changing during a call of the PoC compatible terminal by 2nd Embodiment of this invention.</figref><figref num="9">It is a figure which shows the REFER message format in the process of FIG.</figref><figref num="10">It is a figure which shows the INVITE message format in the process of FIG.</figref>

Code description

1000 CF 1100 PF A 1110 PoC client A1 1120 PoC client A2