Patent Application
20150319112
Not Applicable.
Not Applicable.
There are a large number of communication methods available for one person to communicate with another. As part of this, it is often desirable for one user in a communication system to be able to see the presence state of another user system with who they may wish to communicate. Presence state generally refers to the communication status of a user which can be used to provide other users with an indication of the availability of a user to carry out communication. This presence state cm include a vast number of different statuses such as: available, busy, away, offline, etc. The status of a user may refer to an explicit status set by a user or be derived from the status of a group of devices or clients associated with a user. A user may have multiple statuses depending on which sub group of devices or systems are considered.
Using this information, a first user, user X can determine the status of another user, user Y, without actually initiating a communication. So, for example, if user Y is on a telephone call then their presence state may indicate that they are busy. User X would be able to use this presence state information to determine that there is no need to initiate a telephone call at this stage. This avoids having to actually dial user Y or obtaining an engaged tone. Similarly user X may wish to communicate with user Y using instant messaging (IM). The presence state of user Y on their IM client may indicate that they are available so that user X knows that they can initiate a messaging session.
A user may have a presence state on two different communication mechanisms. For example, user Y may have a presence state in relation to their IM status but also have a presence state in respect of their voice status, i.e. in respect of their telephone usage. In order for user X to establish the presence state of user Y, then they may need to establish the presence state over the two different mechanisms. User Y may have multiple devices connected to the same account over either of the communication mediums. Consequently, user Y may have a significant number of presence states corresponding to each device but it is desirable to have a single presence indicator for user Y. For example if user Y is sitting in front of a computer and has access to an IM client, then their IM status may be “available for chat”. If user Y then receives a telephone call on a SIP phone then their voice or phone status might be busy but their IM status may still show as available. furthermore, if user Y has a mobile phone with an IM client on it, that client may also indicate that it is available.
Therefore, in order for user X to determine the overall presence state of user Y, they may need to establish several different presence indicators over different mechanisms, such as IM or SIP. The devices of user Y which are providing an IM function can provide status information using XMPP (Extensible Messaging and Presence Protocol). Similarly, if user Y uses a voice (SIP) phone, which may be a softphone or a hardphone, the SIP connection status of the phones may be obtained using a SIP “SUBSCRIBE” message to determine the presence state of that device or the SIP account of user Y.
One solution is to use the XMPP connection to provide a single presence indicator for a user.
Consequently, in the example above, the XMPP connection does not have a complete view of the presence information for user Y. Although the softphone can publish presence changes when SIP calls are made on the softphone itself, it is unaware of calls made on the hardphone. Equally, the SIP server does not have a complete view of the presence information. Although user X can subscribe to the presence state of user Y over SIP by issuing a SUBSCRIBE request to the status of user Y's account user X will not receive presence information made exclusively using the XMPP connection such as putting the IM status to do not disturb or status automatically changing to IDLE after a period of user inactivity.
One solution to the problem of user X wishing to see the status of user Y is to send a SIP subscribe message for user Y's SIP account to obtain user Y's SIP status and simultaneously maintain the XMPP connection to obtain XMPP presence information about user Y. Whilst this is not too onerous for a simple two person scenario, obtaining presence information when the number of users increases becomes significantly more challenging.
For example if user X wished to monitor the status of a number of friends then they would need to carry out separate monitoring activities for each of those friends. For the SIP connections, user X must subscribe to each friend's SIP status. Each individual SUBSCRIBE requires a separate session to be maintained, e.g. every 5 minutes each SUBSCRIBE (for each user monitored) must be re-sent, in order to keep the subscription active. To monitor the IM status of his friends, user X establishes an XMPP stream, which is permanently kept open. Any presence subscription sent within that stream remains active for the duration of the stream.
For example, as shown in
It will therefore be apparent that as the number of users in the system increases, the number of subscriptions that need to be maintained may become very large as well as the overhead of serving all of the subscriptions over the network.
In the example above it is assumed that every user wishes to have presence information about each other user in the system. In reality this may not be true. However, even if each user only wishes to subscribe to presence information about a proportion of the other users, the number of active streams and dialogs still increases exponentially roughly proportional to N2.
It is therefor an aim of the present invention to overcome or at least ameliorate some of the problems described above.
According to the present invention there is provided a client for monitoring user presence status comprising: a SIP interface arranged to send a subscription message to a SIP server and to receive SIP status information relating to a SIP account associated with said user, from said SIP server; and an XMPP interface arranged to communicate with an XMPP server to provide status information based on said received SIP status information.
The invention allows a number of users to monitor the status of each other without the need to have an exponentially large number of SIP subscriptions in place. This allows the total number of actively maintained connections required to be significantly less than in the arrangement described above.
The SIP interface is preferably arranged to send a plurality of subscription messages, each subscription message relating to a respective SIP account associated with said user. This allows the user to have multiple SIP accounts but still maintain a single presence status which can be monitored using the invention.
One or more additional interfaces may be included, with each arranged to communicate with respective servers using respective communication protocols to obtain presence information relating to the user. Such additional interfaces can be used to provide the obtained presence information to the XMPP interface to provide status information to the XMPP server. This allows the invention to be used to consolidate presence information for various different domains in additional to SIP and XMPP. For example, one of the additional interfaces could be for communicating with a respective server using H.323.
The SIP interface may be further adapted to be able to receive a call identifier of an incoming call for the user in the SIP status information, and the XMPP interface can then communicate the call identifier to said XMPP server. This allows information about an incoming call for the user to be made available to other users to allow them to receive the call on their behalf. With the call identifier information, the SIP can be uniquely identified and the other user can take the SIP call on with it.
Preferably, the XMPP interface is further arranged to receive presence status information associated with the user from the XMPP server, and the SIP interface is further arranged to send update information to the SIP server based on the presence status information received fey the XMPP interface.
The present invention also provides a method for monitoring user presence status comprising: sending a subscription message to a SIP server; receiving SIP status information relating to a SIP account associated with said user from a SIP server; and providing status information to an XMPP server based on said received SIP status information.
The method may also include sending a plurality of subscription messages, each subscription message relating to a SIP account associated with the user. This allows a user to have multiple monitored SIP accounts.
The method may also include obtaining presence information relating to the user from one or more additional servers, using respective communication protocols; and providing status information to the XMPP server based on the obtained presence information. Preferably, at least one of the respective communication protocols is H.323.
The SIP status information may include a call identifier relating to an incoming call for the user and the call identifier may then be included in the status information provided to the XMPP server.
Preferably, the method also comprises receiving presence status information associated with the user from the XMPP server, and sending update information to the SIP server based on the presence status information received from the XMPP server.
The present invention further provides a system for monitoring user presence status comprising: a SIP server arranged to manage the status of a user SIP account; an XMPP server arranged to manage the status of a user XMPP account; and a user client, wherein said user client is arranged to: send a subscription message to said SIP server; receive SIP status information from said SIP server; and communicate with said XMPP server to provide status information based on said received SIP status information.
The user client may be arranged to send a plurality of subscription messages, each subscription message relating to a SIP account associated with the user.
The user client may be further arranged to communicate with one or more additional servers using respective communication protocols, to obtain presence information relating to the user, wherein the obtained presence information is used to provide status information to the XMPP server. At least one of the respective communication protocols may be H.323.
The SIP status information may include a call identifier relating to an incoming call for the user. The call identifier may then be included in the status information provided to the XMPP server.
The user client may be further arranged to receive presence status information associated with the user from the XMPP server, and the user client may be further arranged to send update information to the SIP server based on the presence status information received from the XMPP server.
The invention may additionally be implemented as computer executable code and the methods, systems and clients referred to above may be implemented as code on suitable devices, to provide the function of the present invention. In particular, the invention may provide a computer program product comprising computer executable code which when executed on a code executing device causes the device to: send a subscription message to a SIP server; receive SIP status information relating to a SIP account associated with said user from a SIP server; and provide status information to an XMPP server based on said received SIP status information.
The invention will now be described in more detail by reference to the non-limiting examples below and the figures in which:
In the example given above, the biggest proportion of the total number of dialogs required to maintain presence information was due to the need for users or user clients to obtain SIP status information for each other user that presence information is required for. In contrast, an XMPP subscription can receive presence updates for all contacts over one stream. As such, the XMPP connection is much more efficient at providing presence information. However, it is unable to directly provide information about a user's SIP status.
In the arrangement shown in
In order to overcome this shortcoming, the softphone Y2 can subscribe to the SIP presence state of user Y, in effect its own presence state, to accurately obtain the SIP status. The SIP protocol, allows for a SIP SUBSCRIBE message to be sent to the SIP server of a registrar for a SIP account. The SIP SUBSCRIBE message identifies the SIP account to be monitored and where any updates are to be sent (the subscriber). The SIP server will then monitor that account and if the status of the account changes, a response will be sent to the subscriber providing an indication of the updated SIP status.
Whilst this SIP SUBSCRIBE message is normally used for monitoring the status of another user's account, in this invention, hardphone Y2 subscribes to its own SIP account status, or specifically the status of the account which Y2 uses to obtain a SIP service. In this way, when a different client, such as hardphone Y1, causes the SIP status to change, for example by initiating a phone call, the SIP server will alert the change in status and update Y2 with this change.
Once softphone Y2 has been provided with this information then it can use it to update the presence information of the SIP account to the XMPP server, over the existing XMPP XML stream (which is always connected). In this way, even though the hardphone Y1 has no direct connection to the XMPP server. Its use of the SIP account can still be communicated to the XMPP server to update the presence information in respect of user Y. In this way, softphone Y2 will effectively provide the SIP account status to the XMPP server, avoiding the need for other users to then determine the SIP status of user Y but instead being able to rely upon the presence master status provided by the XMPP server.
As can be seen from the lower line in
Referring to the arrangement in the example of
As a precursor to this stage, softphone Y2 may initially query the status of the SIP account to establish the initial state. This state information would then be communicated to the XMPP server to confirm or update the initial status information.
Once the SIP server has received a SIP SUBSCRIBE message. It will subsequently update any change in status of the SIP account to the address indicated in the SIP SUBSCRIBE message. In this case the address would relate to softphone Y2. Consequently, when hardphone Y1, or any other device or client wishing to initiate a call on the same SIP account, sends a SIP INVITE message (S2), the SIP server notes this request as a change of status of the SIP account of user Y. As a result the SIP server sends a SIP NOTIFY message back to softphone Y2 indicating the change in presence state from, for example, phone idle to phone ringing. However, different statuses may be indicated for example “in call” or “do not disturb”. In the latter case, the change of a status may not be initiated by hardphone Y1 making a call but instead simply updating the SIP server with its status.
The SIP NOTIFY message (S3) is received by softphone Y2 which then needs to communicate the change in presence status of the SIP account to the XMPP server. The softphone Y2 therefore sends a message to the XMPP server to pass on the change in SIP presence state and hence the new XMPP presence status to the XMPP server. In other words, the softphone Y2 sends a <presence> stanza over the existing XMPP XML stream indicating a new status which is equivalent to the new SIP status.
On receipt of the new <presence> stanza over the XML steam, the XMPP server updates the current presence status of user Y. This changing status is then transmitted (S5) to user X's client X1. In this example,, there are only two users, so the XMPP server only needs to rebroadcast the new presence information to user X, although it may also rebroadcast them to other clients that user Y has (e.g., Y3, Y4) which may need to be updated with a new XMPP status. However, in a system with multiple users, the new presence status for user Y may need to be communicated to a number of other users and their respective clients or devices, who may be interested in the presence status of user Y. This might be done by issuing a broadcast message relating to the status of user Y or fey sending update messages specifically to those users (or buddies) of user Y who would want to be made aware of the status of user Y.
It will be apparent that in the present invention, each user only has to maintain one SIP presence subscription for reflecting their own SIP presence state, and one XMPP XML stream. This is applicable even if they are monitoring the presence state of every available user within the system. It will therefore be apparent that for N users in a system, with all users wishing to monitor the presence status of all other users, then 2N active streams/dialogs would be required, in contrast to the (N+1)2 required in the above example. Furthermore, each additional user only adds two additional streams/dialogs rather than N+1.
The foregoing embodiment relates to a system where a user has a subscription to a single XMPP connection and a single SIP connection. In both cases multiple devices or clients may be associated with the respective connection. In the example of
For example, the user may have two SIP connections and one XMPP connection. The arrangement of
By subscribing to both SIP connections, softphone Y2 would then be advised of any changes of such as due to telephone calls initiating from either account. Therefore, irrespective of which SIP account is used to initiate a call or change the status of a SIP account, the softphone Y2 is updated so that it can then update the presence information on the XMPP server.
Again the embodiment above does not need to be limited to one or more SIP connections or XMPP connections. Instead it may also encompass connections to other protocols, such as H.323. Again the XMPP connection can be used as the master for presence information. A user client acting as an interface can obtain status information from one protocol such as SIP in the example above, but also from a different protocol such as H.323. The client can then update the master XMPP connection to provide an overall presence status for user Y over all three protocols.
In the above embodiment, simple presence information is communicated from the SIP server to the softphone Y2 so that it may update the presence information on the XMPP connection. However, additional information may be provided such as the Call_ID for an active SIP call. This information could then be passed to the XMPP connection, in order for directed call pick-up to be invoked without the user needing to SIP SUBSCRIBE to the SIP presence information for each of their contacts. The SIP protocol allows one user to answer another call. This uses SIP line state monitoring (using SIP SUBSCRIBE).
For example, if one user (Y) wishes to answer calls for another user (X), Y SUBSCRIBES to the status of X. It is then possible for the server to be configured, such that if X receives an incoming call a NOTIFY message indicating the line presence change is sent to Y. This NOTIFY message includes a unique call identifier (call_ID) for the call that is alerting on X's phone. On receipt of the NOTIFY message, Y can answer the phone on behalf of X, for example by pressing a button with an indicator that X's phone is ringing. Y's phone will then send an INVITE message including a REPLACES header, in which the received call_ID is included, signalling that Y wants to ‘grab’ the call with the specified call ID. Y then effectively has answered the call on behalf of X. However, this does require user Y to SIP subscribe to the status of user X.
With the present invention, a user is able to receive a call for other users who are unable to accept a call for example, because they are already in a different call, without having to SIP subscribe to each user. By having the call_ID synchronized through the XMPP server, allowing the Call_ID to be made available in the presence information of the XMPP stream of a user, the invention provides the ability for other users to receive a call on behalf of that user.
So if user Y wishes to receive calls on behalf of user X, they can see if user X is ‘out of call’, ‘ringing’ or ‘in-call’. Then if a new call comes in for user X, user Y can obtain the call_ID through the XMPP server, just like the presence state. They can then take the call, as described above, by sending an INVITE message with a REPLACES header including the Call_ID.
In the above embodiment, the presence information is communicated from the SIP server to provide the SIP status to the XMPP connection to update the XMPP presence information. However, the XMPP presence information could be synchronised in the opposition direction such that the XMPP presence information is available to the SIP server. This kind of information can be used by the SIP server to make routing decisions, bused upon the presence information.
For example, if user Y has an XMPP only client such as the IM client Y3 shown in
In this way, when a call is subsequently received by the SIP server, the changed SIP status can be used to deal with the call appropriately. For example, if the user has updated their IM account status to DND causing the SIP server to be updated to the equivalent status, then the SIP registrar may respond to the incoming call by indicating that the user is “busy” or “unobtainable”. Alternatively, it may redirect the call according to some predefined rules relating to when user Y is not available (or has set their status to DND), such as directing the call to voicemail. Other rules may be used for different statuses. For example if the user bus set their IM status to “Away from office” then this will update the XMPP server status which can be relayed to the SIP server which sets the sip status accordingly. As a result, it may divert an incoming call to a mobile phone instead of to hardphone Y1 and so on.
In this way, a user can change their status on an IM client, which may be on their mobile phone, and indirectly update their SIP status, even though they do not directly access any SIP enabled device.
As indicated above, the invention is not limited to using softphone Y2 as the bridging device between the SIP connection and the XMPP connection. Any means for linking the two connections is sufficient. Any client or device may be used that is able to send SIP subscribe messages and receive SIP NOTIFY messages and use that information to update the XMPP server. Furthermore, the client may not be the only client of user Y which provides this service it is possible that multiple devices or clients associated with user Y provide the same service even though this may introduce replication. However, this ensures that if, for example, softphone Y2 was provided on a laptop that was turned off, a further device would be able to directly update the XMPP server with changes in the presence status of the SIP account. Even if there was duplication in the update process, the end result should be the same. For example if a SIP call was initiated and two clients for user Y had subscribed with the SIP server to receive notification messages, then both will receive notification messages. In response, both clients would send update information to the XMPP server. The first update might change the status for user Y held by the XMPP server but the second message would have no effect as its indicated new status would already be set.
It should be noted that in
The XMPP and SIP servers shown in
The present invention may be implemented in any number of devices and is not intended to be limited to the examples above. For example, it may be implemented on a softphone; a hardphone; in a standalone client which has no user IM or SIP interface but simply acts as the intermediary between the SIP and XMPP domains; etc. The invention may also be implemented on a server, PC, smartphone, or any other similar or equivalent device. The implementing device may be a device which the user uses as a communication device such as a SIP phone or IM client, or may be a separate device which may even be remote from the user, for example hosted on a server in a different location.
References to H.323 in this document refer to the H.323 standard of the Telecommunication Standardization Sector of the ITU (International Telecommunication Union).
