Handling of invitations to group communication sessions

BACKGROUND OF THE INVENTION

00011. Field of the Invention

0002The invention relates to a method for controlling group communication and a group communication server in a communication network.

00032. Description of the Related Art

0004A prior art group communication server is disclosed, for example, in document US2002/0150091. In detail, in this document the group communication server is a call processing server being responsible for a control plane management of group communications.

0005The present invention relates in particular to an environment that uses SIP (Session Initiation Protocol) to establish sessions between users.

0006Currently, when a SIP session to a number of invitees is initiated, the SIP conference server sends the invitations (INVITE messages) to all group members. In case that some intended user was not registered to the SIP core network during the original session initiation, the participant will not receive an invitation. In case that the user registers to the SIP core at a later stage, but though during the conference existence, and even though she/he could potentially wish to join the conference, she/he is not informed of the attempt to bring her/him into the conference. Moreover, the SIP core of the non-registered terminal returns a final response, which finalizes the SIP session establishment procedure towards that particular user.

0007Currently there does not exist a mechanism to late join to a particular session that was invited earlier. Potentially, the user that registers to SIP core late, when a conference still exists, which is also intended for him/her, the subscriber could get knowledge of the existing conference by e.g. subscribing to conference state package.

0008That is, at present it is not possible for late registered users to be aware of a conference session and thus join the a conference, for which already invitations were issued.

0009In particular, this problem occurs in case potential participants of a conference were not registered to the network (e.g., are located in an area with no connectivity, or have their SIP device switched of).

0010Namely, in detail, a SIP User Agent creates a conference, and provides instructions to the conference server to dial-out a number of potential participants. The conference server sends an INVITE request to each of the potential participants, as described above. Out of those potential participants, some accept the invitation, and become participants of the conference. Others either reject the invitation (perhaps are busy), don't answer the call, are located in an area where there is no connectivity, or have the SIP device switched off.

0011Those potential participants that were logged into the network, but didn't accept/answer the call, will receive an indication of a missed call in their terminal's log, and thus, can join the conference at a later stage, if they wish. But the problem is that those potential participants that were not registered to the network (due to lack of coverage/connectivity, flat battery or phone switched off) will never be informed of the conference invitation. In case any of these potential participants become available (due to coverage/connectivity or phone switched on), they are not aware of the existence of the conference, and, thus, are not able to join the conference, if still is taking place.

0012The invitations for a session/conference may also include a unique session identifier (e.g., URI (Uniform Resource Identifier), SIP Call ID or similar) which is needed to join the session. The session identifier may be assigned per session basis (temporary identifiers). In this case, late registered users cannot know the session identifier which makes joining the session impossible even if they were aware of the session's existence.

SUMMARY OF THE INVENTION

0013Hence, it is an object of the present invention to solve the problem mentioned above and enable users to join a group communication session which started when the user was not registered, not available, or the like.

0014This object is solved by a method for controlling group communication in a communication network. This method comprises the steps of sending, to a plurality of users, requests to join a group communication session, detecting that at least one of the users was not accepting the request to join the group communication, and subscribing to a status of the at least one of the users not joining the group communication session.

0015Alternatively, this object is also solved by a group communication server in a communication network, comprising means for sending, to a plurality of users, requests to join a group communication session, means for detecting that at least one of the users was not accepting the request to join the group communication, and means for subscribing to a status of the at least one of the users not joining the group communication session.

0016The status described above may be a registration status or a presence status, for example.

0017That is, after an unsuccessful invitation to a user to join a group communication session, a subscription is performed to the status (either the registration or the presence information) of this particular user. Hence, after registering of this user, or after the publication of the user's presence status, the sender (i.e., the group communication server) is notified of the registration or presence availability status and can send a further invitation to a group communication session.

0018Hence, in this way a user which registers after the invitation to a group communication session has already been issued (or was not available, is busy or does not answer etc.) can get knowledge of the existence of the group communication session, and can take part in the group communication session.

0019Thus, the group communication server (the conference server) may act as a watcher of the registration or presence information of a user, when the user is not connected to the network or not available.

0020Further advantageous developments are set out in the dependent claims.

BRIEF DESCRIPTION OF THE DRAWINGS

0021The invention is described by referring to the enclosed drawings, in which:

0022<figref idref="DRAWINGS">FIG. 1</figref> shows a network configuration comprising a conference server and a plurality of potential participants of a conference according to any of the embodiments of the invention,

0023<figref idref="DRAWINGS">FIG. 2</figref> illustrates a message flow between the conference server and the SIP cores of the potential participants upon inviting to a conference according to a first embodiment,

0024<figref idref="DRAWINGS">FIG. 3</figref> shows a message flow between the conference server, a late-registered participant and its SIP core after registering of this participant according to the first embodiment,

0025<figref idref="DRAWINGS">FIG. 4</figref> shows a detecting procedure according to the first embodiment for detecting whether a user not responding to the conference invitation is registered or not,

0026<figref idref="DRAWINGS">FIG. 5</figref> illustrates a message flow between the conference server and the SIP cores of the potential participants upon inviting to a conference according to a second embodiment,

0027<figref idref="DRAWINGS">FIG. 6</figref> shows a message flow between the conference server, a late participant and its SIP core and presence server after this participant publishes his/her presence information, according to the second embodiment,

0028<figref idref="DRAWINGS">FIG. 7</figref> shows a detecting procedure according to the second embodiment for detecting whether a user not responding to the conference invitation is available or not, and

0029<figref idref="DRAWINGS">FIG. 8</figref> shows a message flow for handling a change of the S-CSCF of a non-registered user.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

0030In the following, preferred embodiments of the present invention are described by referring to the attached drawings.

0031According to the first embodiment of the present invention, a mechanism for SIP core/network system is proposed, by which it is possible to send invitations to an existing group session for a user (participant) who performs registration to a SIP server at a later stage, i.e., when the conference session already exists and the user was not yet registered to SIP when the initiation procedure was performed.

0032Technically this is implemented such that a conference server (as an example for a group communication server) controls the existing and originally invited session, subscribing the registration information state of each of the invited users for which the conference server got a response indicating that he/she was not registered to the SIP core. In this case, once the late user registers to the SIP core, the controlling SIP server would get knowledge on that, and consequently would be able to send a new INVITE request also to this late registered user.

0033In the following, this procedure is described in more detail by referring to <figref idref="DRAWINGS">FIGS. 1 and 2</figref>.

0034<figref idref="DRAWINGS">FIG. 1</figref> shows a network system illustrating the conference server <b>1</b>, and a plurality of potential participants A to D (denoted with reference signs <b>2</b> to <b>5</b>, respectively). The conference server comprises a sender/receiver <b>11</b> (as an example for a sending means) and a processor <b>12</b> performing several operations to be described later.

0035It is noted that the SIP core as used throughout the description is a network entity controlling SIP network of a participant (user) and typically comprises e.g. session control, routing, registrar and charging means/elements.

0036In this example, the following situation is assumed:

0037User A instructs the conference server <b>1</b> to initiate a group session to users B, C and D. Users B and D are registered to the SIP core at the time the conference server sends the invitation, and consequently, they are able to receive INVITE messages. Furthermore, they are able to join the session (conference).

0038User C is not registered to SIP core at the time the conference server sends the invitations to the users. This is illustrated in <figref idref="DRAWINGS">FIG. 1</figref> by dashed lines, wherein no connection exists between the conference server and the user C (<b>4</b>). Due to the user C not being registered, his/her SIP core returns a final response for the INVITE that indicates that the user C is not registered (480 Temporarily Unavailable response in any SIP network, including 3GPP IMS (Internet Protocol Multimedia Subsystem)).

0039This is illustrated in the message flow diagram shown in <figref idref="DRAWINGS">FIG. 2</figref>. It is noted that in the message flow diagram of <figref idref="DRAWINGS">FIG. 2</figref> and also in the other following message flow diagrams only those messages are illustrated which are helpful to explain the present invention, whereas other messages/procedures requiring for setting up the connection and the like are omitted for simplifying the description.

0040As shown, the conference server <b>1</b> sends INVITE messages M<b>1</b>, M<b>2</b>, and M<b>3</b> to the users (the potential participants) B, C and D. It is noted that in <figref idref="DRAWINGS">FIG. 2</figref> only the messages between the SIP core servers of B, C and D are shown, and the messages between the SIP core servers and the corresponding user terminals <b>3</b>, <b>4</b> and <b>5</b> of the users B, C and D are omitted for simplifying the illustration.

0041As mentioned above, users B and D are registered, so 200 OK messages M<b>4</b> and M<b>5</b> are sent back to the conference server (assuming that the users B and D would like to participate in the conference). Since user C is not registered, the SIP core sends a 480 Temporarily Unavailable response M<b>6</b> back to the conference server.

0042Once the conference server receives the response indicating a non-registered status (i.e., the 480 Temporarily Unavailable response), it subscribes to user's C registration status by sending a SUBSCRIBE request for the “reg” event (registration event) to the user's C SIP core of in message M<b>7</b>.

0043If the session ends before the user C registers, the conference server unsubscribes the reg event by sending a SUBSCRIBE request with the Expires header field set to zero.

0044In the following, the situation when the user C registers and the conference has not ended yet is described by referring to <figref idref="DRAWINGS">FIG. 3</figref>, where also the messages between the SIP core server and the corresponding user terminal can be seen. When the user C registers by sending a REGISTER message M<b>11</b> to its SIP core server, the SIP core of user C sends a NOTIFY message M<b>12</b> containing the user's registration status to the conference server, thus it gets knowledge of the registration of the user C.

0045Once the conference server receives the notification, it invites the user C to the session by sending a further INVITE message M<b>13</b> to the SIP core of user C. This is forwarded to the user C in message M<b>14</b>. In this example it is assumed that the user C would like to participate in the conference, so a 200 OK message M<b>15</b> is sent to the SIP core, and is forwarded in message M<b>16</b> to the conference server. Thus, the user C is informed of the existence (activity) of the conference and may join the conference.

0046The INVITE messages may also include a unique session identifier (e.g., URI, SIP Call ID or similar) which is needed to join the session (conference). The session identifier may be assigned per session basis (temporary identifiers). As described above, user C receives a further INVITE message M<b>13</b>, which includes the session identifier in this case. Hence, he gets the session identifier necessary to join the conference and can join it.

0047In <figref idref="DRAWINGS">FIG. 4</figref>, an example of a procedure for detecting the reason why a user does not accept the invitation is illustrated.

0048The procedure is carried out each time a response to an INVITE message is received. In step S<b>1</b>, it is checked whether a 480 Temporarily Unavailable response has been received. If this is not the case, no further detection is necessary, and the procedure ends.

0049If the user is not registered, so that a 480 Temporarily Unavailable response was received, the procedure proceeds to step S<b>2</b>, in which the subscription to the user's reg event status is performed (i.e., the message M<b>7</b> shown in <figref idref="DRAWINGS">FIG. 2</figref> is sent to the SIP core of user C).

0050In a second embodiment described in the following by referring to the message flow diagram shown in <figref idref="DRAWINGS">FIG. 5</figref>, the situation is considered as an alternative to the first embodiment. That is, in contrast to the first embodiment, the conference server gets richer information of the availability of the user by subscribing to the presence status of those users that do not succeed in joining the conference. For instance, the conference server may get information that the user is away from his keyboard, busy, in a meeting, not registered, etc., and it will send a new invitation as soon as the user changes its presence information to available. Furthermore, the conference server may get from the presence information an indication of an alternative way to reach the intended user (e.g. reachable via another address) or another contact person that is able to attend the conference (e.g., a secretary or a member of the family).

0051According to <figref idref="DRAWINGS">FIG. 5</figref>, the conference server sends INVITE messages M<b>21</b>, M<b>22</b>, and M<b>23</b> to the users (the potential participants) B, C and D. B and D are registered and joining the conference, so 200 OK messages M<b>24</b> and M<b>25</b> (similar to messages M<b>4</b> and M<b>5</b> shown in <figref idref="DRAWINGS">FIG. 2</figref>) are sent back to the conference server. Since user C is not registered, the SIP core sends a 480 Temporarily Unavailable response M<b>26</b> (corresponding to message M<b>6</b> shown in <figref idref="DRAWINGS">FIG. 2</figref>) back to the conference server, similar as described in connection with the first embodiment.

0052Once the conference server receives the response indicating a non successful result (i.e., any 400-class, 500-class or 600-class response) or the user does not answer and the INVITE request times out, it subscribes to user's C presence information status by sending a SUBSCRIBE request for the presence event to user's C SIP core in message M<b>27</b>. User's SIP core will further route the message M<b>28</b> to user's C presence server. This is acknowledged by the user's C presence server by sending a 200 OK message M<b>29</b> to the SIP core of C, which forwards this 200 OK message to the conference server in message M<b>30</b>.

0053User's C presence server will send a NOTIFY request containing presence information in message M<b>31</b>, which is received by the conference server (message M<b>32</b>). This is acknowledged by the conference server by sending an 200 OK message via the SIP core of C to user's C presence server (messages M<b>33</b> and M<b>34</b>). At this point in time, the conference server is able to determine if there are alternative ways to reach the user or alternative contacts (e.g., a secretary or a member of the family) for user C, in which case the conference server may immediately send a new INVITE to this alternative contact.

0054If the session ends before the user C changes its presence information to available, the conference server unsubscribes the presence information event by sending a SUBSCRIBE request with the Expires header field set to zero.

0055It must be noted that if the presence information of the user reveals that he is registered to the SIP core, but not available (e.g., he is away from his SIP device), then the conference server may send periodic INVITE requests to such user, in case the alerting tone at user's C terminal brings the user's attention, and he may join the conference.

0056In the following, the situation when the user C changes its presence information and the conference has not ended yet is described by referring to <figref idref="DRAWINGS">FIG. 6</figref>. It is worth noting that in the following description it is assumed that the user C publishes his own presence information (by sending a PUBLISH request), but this need not be the case. Any authorized entity that has gotten user's C presence information can publish it. For instance, a SIP registrar (such a S-CSCF in 3GPP IMS) can publish user's C presence information upon registration of user C.

0057According to <figref idref="DRAWINGS">FIG. 6</figref>, the user C sends a PUBLISH request M<b>41</b> to indicate a change in his presence information, such as, the user is available now. This request is received by user's C presence server (acknowledging this with the 200 OK message M<b>42</b>), which sends a NOTIFY request M<b>43</b> to all the subscribed parties, among others, the conference server. This NOTIFY request contains the change in user's C presence information. The SIP core routes the message to the conference server (M<b>44</b>). The NOTIFY request is acknowledged by the 200 OK messages M<b>45</b> and M<b>46</b> sent to the SIP core of C and from there to user's C presence server. The conference server analyzes the presence information, and since user C is now available, and since (in this example) the conference is still going on, sends a new INVITE request M<b>47</b> to user C. This message is routed through the SIP core and eventually delivered to user C (M<b>48</b>), who gets knowledge of the existing conference and can join it (wherein C acknowledges the INVITE request by sending a 200 OK message M<b>49</b> to the SIP core C, which forwards it to the conference server in message M<b>50</b>).

0058<figref idref="DRAWINGS">FIG. 7</figref> shows an example of the detection procedure illustrated, similar as that shown in <figref idref="DRAWINGS">FIG. 4</figref> in connection with the first embodiment.

0059The procedure is carried out each time a reaction to an INVITE message is received. In step S<b>11</b>, it is checked whether a 400, 500, or 600-class response has been received. If this is not the case, no further detection is necessary, and the procedure ends.

0060However, if a 400-, 500-, or 600-class response is received, then the procedure proceeds to step S<b>12</b>, in which the conference server subscribes to the user's presence information. Alternatively, the conference server may subscribe to the user's presence information only when certain predefined responses are received.

0061It is noted that it is not necessary to trigger the subscription on any 400-, 500- or 600-class response. That is, the conference server may comprise a predefined set (or list) of responses which trigger the subscription. This set of responses may be a subset of the 400-, 500- and 600-class responses, and/or may contain also other suitable responses.

0062Furthermore, as described above, instead of detecting the 400-, 500- or 600-class response, alternatively also a timer can be used. That is, if the timer times out after sending the INVITE request, then the conference server may subscribe to the user's presence information.

0063As described above, when the conference server does not receive a positive answer (200 OK) from any of the potential participants, the conference server subscribes to the presence state of such potential participant. The presence subscription will inform user's availability to the conference server when the availability information changes. According to the first or the second embodiment, the conference server can send a periodic invitation (e.g., every 15 minutes), if the user is online. If the user is offline, the conference server can send an invitation when the user becomes online and publishes his online status.

0064The conference server sends an INVITE request to each of the potential participants. If a potential participant accepts the session (e.g., answers with a 200 OK response), then the conference server inserts it as a participant in the conference, and no further actions are needed.

0065If a potential participant does not become a participant (rejects the session, does not answer, is not registered, etc.), the conference server may subscribe to the potential participant presence information by sending a SUBSCRIBE request with the Event header field set to presence.

0066With respect to first embodiment, the following is noted with respect to de-registering of the user. In detail, when the user de-registers, his S-CSCF (Serving Call Session Control Function) allocation is released. Once the terminating request (here SUBSCRIBE) is received by the IMS and the user is unregistered, the IMS may allocate a new S-CSCF to perform user's services. IMS should allocate the S-CSCF if the user has services that need to be performed for unregistered user. Once the user registers, the IMS again allocates a new S-CSCF to perform the services for registered user. This means the S-CSCF which received the SUBSCRIBE for reg event may be different from the one that receives the user registration indication, thus the IMS is not able to send NOTIFY for reg event back to the reg event subscriber.

0067This problem may be solved in the following way. Reg event subscriptions will be routed to dedicated Application Server (AS). This can be achieved by using iFC (initial Filter Criteria) in the S-CSCF. Also user registrations and de-registrations are routed to the same AS. Also this can be achieved by using iFC (this is so called 3^rdparty registration, IMS registers to the AS on behalf of the user). This means the AS that receives the reg event subscriptions is aware of the user registration status, and thus is able to send NOTIFY for reg event.

0068This is shown in <figref idref="DRAWINGS">FIG. 8</figref>. As shown, the subscription is performed by message M<b>52</b> with the AS. The SUBSCRIBE is routed to AS via S-CSCF of user C, after the conference server has sent message M<b>51</b>: SUBSCRIBE (reg event) to the present S-CSCF <b>1</b> of user C. The subscription is confirmed via 200 OK messages M<b>53</b> to M<b>54</b>. The AS responds with the current registration status of the User C (here unregistered), that is messages M<b>55</b>-M<b>56</b> (NOTIFY) in <figref idref="DRAWINGS">FIG. 8</figref>. This is confirmed via 200 OK messages M<b>57</b> to M<b>58</b>. Thus, after user C registers by sending a REGISTER message M<b>59</b> to its S-CSCF (which may now be a different S-CSCF than the one via which the SUBSCRIBE was routed in previous step), the S-CSCF (in this case, S-CSCF <b>2</b>, i.e., a different S-CSCF) performs a third party registration to the AS and sends a REGISTER message M<b>61</b> to the dedicated Application Server. The REGISTER messages M<b>59</b> and M<b>61</b> are confirmed by 200 OK messages M<b>60</b> and M<b>62</b>, respectively.

0069The application server sends a NOTIFY message to the conference server in messages M<b>63</b>-M<b>64</b>, indicating user C's registration status (here registered), which are confirmed by 200 OK messages M<b>65</b> and M<b>66</b>. After this, the conference server sends an INVITE message M<b>67</b> towards the user C (via S-CSCF <b>2</b> and message M<b>68</b>). In case user C accepts, a 200 OK message is sent back to the conference server (this message is not shown in the figure).

0070In case of OMA (Open Mobile Alliance) PoC (Push-to-talk over Cellular) service and 3GPP IMS, the dedicated AS mentioned above is user's participating PoC server. The reg event subscription is sent from controlling PoC server. These two PoC servers can be located in different domains, since there is NNI (Network-to-Network Interface) in place between the domains, and both domains are trusted, so the subscribed domain can trust to send the NOTIFY to the subscribing domain.

0071The invention allows the maximum participation of potential participants in a conference. For the operator, it creates the maximum revenue, since it maximizes the participation of users in conferences.

0072As mentioned above, the invention can be used in PoC environments, because a PoC group is just a conference. It can also be used in 3GPP IMS or any other SIP network that provides conference services based on SIP.

0073The invention is not limited to the embodiments described above, and various modifications are possible.