U.S. patent application number 12/651855 was filed with the patent office on 2010-04-29 for system and methods for providing presence services in ip network.
This patent application is currently assigned to 3COM CORPORATION. Invention is credited to David Grabelsky, Michael Homeier, Anoop Tripathi, Guanglu Wang.
Application Number | 20100107226 12/651855 |
Document ID | / |
Family ID | 42103316 |
Filed Date | 2010-04-29 |
United States Patent
Application |
20100107226 |
Kind Code |
A1 |
Grabelsky; David ; et
al. |
April 29, 2010 |
System and Methods for Providing Presence Services In IP
Network
Abstract
A system and methods are shown for providing presence state
services in an Internet Protocol network. One exemplary system
includes a central presence element configured to track and provide
user presence state information, and a local presence element in
communication with the central presence element and further in
communication with a signaling entity. According to one embodiment,
the local presence element is configured to create and manage local
presence state authorization data generated based on user presence
state information being received from the central presence element.
Further, the local presence element is configured to authorize a
user service request using the local presence authorization data
before providing access to a service requested by the user in the
user service request.
Inventors: |
Grabelsky; David; (Skokie,
IL) ; Tripathi; Anoop; (Naperville, IL) ;
Homeier; Michael; (Los Gatos, CA) ; Wang;
Guanglu; (Kildeer, IL) |
Correspondence
Address: |
MCDONNELL BOEHNEN HULBERT & BERGHOFF LLP
300 S. WACKER DRIVE, 32ND FLOOR
CHICAGO
IL
60606
US
|
Assignee: |
3COM CORPORATION
Marlborough
MA
|
Family ID: |
42103316 |
Appl. No.: |
12/651855 |
Filed: |
January 4, 2010 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10120152 |
Apr 10, 2002 |
|
|
|
12651855 |
|
|
|
|
Current U.S.
Class: |
726/4 |
Current CPC
Class: |
H04L 63/102 20130101;
H04L 67/24 20130101 |
Class at
Publication: |
726/4 |
International
Class: |
G06F 21/00 20060101
G06F021/00 |
Claims
1-26. (canceled)
27. A signaling server comprising computer readable memory, the
signaling server configured to receive a signaling message from a
presence entity, the signaling message comprising a request to
establish a media pathway, the signaling server further configured
to store in its computer readable memory local presence
authorization data in a local database, the local presence
authorization data being specific to each of a subset of a
plurality of users, the signaling server further configured to
authenticate and authorize the request based upon information
specified in the request in conjunction with the local presence
authorization data, and to signal a media proxy to establish the
media pathway if the request is authorized, and the signaling
server further configured to generate the local presence
authorization data (i) from user presence information for the
plurality of users obtained from a central server, and (ii) in
response to communication requests from a user via the presence
entity to enable communications between the user and each of the
subset of the plurality of users, wherein the user is not one of
the subset of the plurality of users.
28. The signaling server of claim 27, wherein the signaling server
comprises a SIP proxy server.
29. The signaling server of claim 27, wherein the signaling server
accesses a message dispatch facility configured to authorize the
request before the signaling server provides the access to a
service specified in the request.
30. The signaling server of claim 29, wherein the request to
establish a media pathway comprises a request to interconnect a
plurality of pre-established data paths between a plurality of
presence entities and a media proxy.
31. The signaling server of claim 29, wherein the media proxy is an
IP conference server.
32. The signaling server of claim 29, wherein the signaling server
comprises the message dispatch facility.
33. The signaling server of claim 29, wherein the signaling server
comprises the message dispatch facility and is configured to
receive user presence state information from the central server,
and wherein the message dispatch facility is configured to receive
the user presence state information and create the local presence
authorization data based on the user presence state information
received from the central server, and wherein the message dispatch
facility is further configured to authorize the request using the
local presence authorization data.
34. The signaling server of claim 33, wherein the user presence
state information comprises at least one authorized watch list for
at least one presence entity, and wherein the message dispatch
facility is configured to use the at least one authorized watch
list to create at least one authorized dispatcher list for at least
one presence entity specified in the authorized watch list, and
wherein the message dispatch facility is configured to use the at
least one authorized dispatcher list to authorize the request.
35. The signaling server of claim 33, wherein the message dispatch
facility is configured to receive presence state change information
from the central server, and, responsively updates the local
presence authorization data based on the presence state change
information.
Description
FIELD OF THE INVENTION
[0001] The present invention relates to communications in mobile
Internet Protocol ("IP") networks. In one aspect of a preferred
embodiment, it relates to providing IP-based presence services.
BACKGROUND OF THE INVENTION
[0002] With the rapidly growing interest in wireless communications
and Internet connectivity, wireless service providers are competing
to capture the market share by offering their customers access to
applications that take advantage of both technologies.
[0003] In a mobile Internet Protocol network, a mobile
communication device (a mobile node), such as a mobile host or
router that changes its point of attachment from one network to
another, communicates with a target host on an Internet Protocol
("IP") network by means of two devices, a "foreign agent" and a
"home agent." Typically, the foreign agent's functionality is
incorporated into a router on a mobile node's visited network. The
foreign agent provides routing services for the mobile node while
it is registered with the home agent. For example, the foreign
agent de-tunnels and delivers data packets that were tunneled by
the mobile node's home agent to the mobile node.
[0004] A home agent is typically incorporated into a router on a
mobile node's home network. The home agent maintains current
location information for the mobile node. When one or more home
agents are handling calls for multiple mobile nodes simultaneously,
the home agents are providing, in essence, a service analogous to a
virtual private network service.
[0005] Mobile Internet Protocol requires the link layer
connectivity between a mobile node (a mobile entity) and a foreign
agent. However, in some systems the link layer from the mobile node
may terminate at a point distant from the foreign agent. Such
networks are commonly referred to as third-generation (3G) wireless
networks. A 3G network delivers much greater network capacity than
many currently existing circuit-switched digital mobile networks.
The increased availability of bandwidth in 3G networks opens up a
new generation of applications to wireless subscribers such as
collaborative and multimedia services.
[0006] One of the goals of the architecture of next generation IP
networks is a framework for the introduction of new multimedia
services and features at the Internet speed, using IP-based
applications and protocols. This has led to a differentiation of
the functional and operational aspects of multimedia networks
within three layers or planes, defined broadly as media processing,
control and service creation. The service creation plane is
sometimes further subdivided into an application plane and a data
plane. The initial next generation IP networks have been aimed at
building the infrastructure that realizes the architectural
framework. At the same time, the list of IP-based multimedia
services ready for deployment has grown steadily ahead of what may
eventually be a great multiplicity of new services and features.
Thus, the successful introduction of the next-generation services
depends not only on how useful the services are to end users, but
also on how intelligently they integrate capabilities of the
underlying network system.
[0007] Many next-generation services, such as an instant messaging
service, require that a user knows the state of other users with
respect to connectivity and availability and their willingness to
communicate, i.e., presence information, that is provided by a
presence service. A presence service is the implementation of the
methods and protocols to realize the practical use of network
presence in real services, which require presence-related
information. An example of a presence-based service is an instant
text messaging service, where one user may detect the presence of
another user and then send an immediate text message to that
user.
SUMMARY OF THE INVENTION
[0008] The system and method described herein are for providing
presence state services in an Internet Protocol network.
[0009] One exemplary system includes a central presence element
configured to track and provide user presence state information,
and a local presence element in communication with the central
presence element and further in communication with a signaling
entity. According to one embodiment, the local presence element is
configured to create and manage local presence state authorization
data generated based on user presence state information being
received from the central presence element. Further, the local
presence element is configured to authorize a user service request
using the local presence authorization data before providing access
to a service requested by the user in the user service request.
[0010] These as well as other aspects and advantages of the present
invention will become more apparent to those of ordinary skill in
the art by reading the following detailed description, with
reference to the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
[0011] Exemplary embodiments of the present invention are described
with reference to the following drawings, in which:
[0012] FIG. 1 is a functional block diagram illustrating an
embodiment of a network architecture suitable for application in
the present invention for providing presence services in an IP
network according to an exemplary embodiment;
[0013] FIG. 2 is a block diagram illustrating a network
architecture illustrating data resources, functional facilities and
network components according to an exemplary embodiment;
[0014] FIG. 3 is a block diagram illustrating a network
architecture for a distributed presence service element according
to an exemplary embodiment;
[0015] FIG. 4 is a block diagram illustrating a network
architecture for a centralized presence service element according
to an exemplary embodiment;
[0016] FIG. 5 is a flow chart illustrating a method for user
processing a user's request to register and go online according to
an exemplary embodiment;
[0017] FIG. 6 is a flow chart illustrating a method for
initializing a state change request according to an exemplary
embodiment;
[0018] FIG. 7 is a flow chart illustrating a method for validating
subscription requests according to an exemplary embodiment;
[0019] FIG. 8 is a flow chart illustrating a method for updating
current subscriber list of willing notifiers according to an
exemplary embodiment;
[0020] FIG. 9 is a flow chart illustrating a method for updating
local authorized dispatcher lists according to one exemplary
embodiment;
[0021] FIG. 10 is a flow chart illustrating a method for completing
a state change request according to an exemplary embodiment;
[0022] FIG. 11 is a message flow illustrating a method for
processing a user's request to register and go online according to
an exemplary embodiment;
[0023] FIG. 12 is a flow chart illustrating a method for changing a
presence state of a user according to an exemplary embodiment;
[0024] FIG. 13 is a message flow illustrating a method for
processing a user's request to change a user's presence state
according to an exemplary embodiment;
[0025] FIG. 14 is a flow chart illustrating a method for
subscribing to a presence entity as a watcher according to an
exemplary embodiment;
[0026] FIG. 15 is message flow illustrating a method for
subscribing to a presence entity as a watcher according to an
exemplary embodiment;
[0027] FIG. 16 is a flow chart illustrating a method for
subscribing to a presence entity as a solicitor according to an
exemplary embodiment;
[0028] FIG. 17 is a flow chart illustrating a method for retrieving
presence state information from user presence state resources
according to an exemplary embodiment;
[0029] FIG. 18 is a message flow illustrating a method for
subscribing to a presence service entity as a solicitor according
to an exemplary embodiment;
[0030] FIG. 19 is a flow chart illustrating a method for
dispatching a message according to an exemplary embodiment;
[0031] FIG. 20 is a flow chart illustrating a method for validating
dispatcher requests according to an exemplary embodiment;
[0032] FIG. 21 is a message flow illustrating a method for
requesting a message dispatch according to an exemplary
embodiment;
[0033] FIG. 22 is a flow chart illustrating a method for canceling
subscriptions according to an exemplary embodiment; and
[0034] FIG. 23 is a message flow illustrating a method for
canceling a subscription to one or more presence entities according
to an exemplary embodiment.
THE DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(S)
[0035] FIG. 1 is a functional block diagram illustrating an
embodiment of a network architecture 100 suitable for application
in the present invention for providing distributed presence
services in an IP network. The network architecture includes a
network 104 such as a world wide web or a public network that
provides a communication path between a presence entity 102 and a
presence entity 106. According to an exemplary embodiment, a
presence entity is an entity possessing a presence state and able
to participate in presence-based services. It should be understood
that the presence entity may represent a user's client device, or a
software entity, such as a service. The presence entities 102 and
106 may take any suitable form such as, for example, a telephone, a
computer, or a personal digital assistant ("PDA"). The presence
entities 102 and 106 are connected to the network 104 via
communication links 116 and 126 that may include a wireless
communication link, a wireline communication link, or a combination
thereof.
[0036] The network 100 for providing distributed presence services
includes a local element illustrated with two local presence
elements 108 and 112, and a centralized presence element 110.
According to an exemplary embodiment, the distributed presence
architecture is based on dividing presence-related network traffic
into two categories: low-volume messages associated with global
data, and high-volume messages associated with local data. In one
embodiment, the low-volume messages are associated, for example,
with user presence state information and tracking, e.g., going
online or offline, or requesting to subscribe to another user's
presence, etc. The high-volume messages are associated with sending
of user-data between users, i.e., the actions users take based upon
the underlying global information. According to the embodiment
illustrated in FIG. 1, the local presence entities are configured
to process the high-volume messages, and the central presence
element 110 is configured to process the low-volume messages.
[0037] The local presence element 108 and 112 may be implemented in
communication with signaling entities such as SIP proxy servers,
and, in one embodiment, the local presence element 108 and 112 may
be implemented on the signaling entities. Further, when the local
presence elements 108 and 112 are implemented on SIP proxy servers,
the SIP proxy servers may act as intermediaries for
presence-related messages being sent between users at client
devices and the centralized elements of the presence service, such
as the central presence element 110, as will be described in
greater detail below.
[0038] In the embodiment, in which the local presence elements 108
and 112 are implemented on SIP proxy servers, the presence entities
102 and 106, such as client devices, may include SIP user agents
that represent users at the client devices to SIP protocol elements
of the network 100. Alternatively, if a client device does not have
an internal SIP user agent, the client device may communicate with
a SIP virtual user agent that may be implemented in the network 100
and may act on behalf of that client device. In such an embodiment,
the client device may be preprogrammed with an additional protocol
that is used for remote communications between the client device
and the SIP virtual user agent. More information on the SIP virtual
user agent can be found in the U.S. patent application Ser. No.
10/021,171, entitled "System and Method for Providing Instant
Services in Internet Protocol Network," filed on Dec. 12, 2001,
fully incorporated herein by reference.
[0039] Further, in one embodiment, the central presence element 110
may be implemented on an authorization/authentication/accounting
("AAA") server. In such an embodiment, in addition to providing
centralized presence services, the AAA server also provides typical
services related to authenticating and authorizing users to access
specific services of the system. Network entities in the network
100 may communicate with the AAA server using any standard or
proprietary protocols, such as RADIUS or 3Q, for example.
[0040] The exemplary embodiments that will be described hereinafter
will be described in reference to presence entities including users
at client devices. However, as mentioned in earlier paragraphs, a
presence entity may also represent a service that requires presence
state information. For example, a user may subscribe to a messaging
service that sends a message to a user when a predetermined state
change occurs, such as a change in a certain stock price, etc. In
such an embodiment, the presence entity may determine subscribers
who subscribed to that service, and then, based on their presence
state information in the system (such as an online state and
availability to receive messages), the presence entity may send
messages to those entities. A different embodiment of a service may
involve tracking locations of one or more subscribers. In such an
embodiment, when a presence entity determines that a user is at a
predetermined location, the presence entity may send a notification
message to subscribers that are subscribed to that location and
that user. Different embodiments are possible as well.
[0041] Further, according to an exemplary embodiment, the network
100 may include a media/message proxy (not shown) in communication
with a signaling entity such as a SIP proxy server. The
media/message proxy may be used as a virtual switch for connecting
a media/message path between presence entities, i.e, an entity,
such as a user's client device or a software entity (e.g., a
service), possessing a presence state and able to participate in
presence-based services. In a network, in which a media/message
proxy is used, SIP user agents on the client devices are connected
via the media/message proxy. A media/message proxy may be used for
security and privacy purposes to prevent unauthorized users from
accessing services since users would first communicate with the
media/message proxy before being able to access any service. The
privacy provided by the media/message proxy allows users to
communicate with each other without ever having to reveal their
actual IP contact information. An example of a media/message proxy
is a conference server that enables users to send instant voice
messages depending on presence states of the users in the network.
The conference server is fully described in the U.S. patent
application Ser. No. 10/021,171, entitled "System and Method for
Providing Instant Services in Internet Protocol Network," filed on
Dec. 12, 2001, fully incorporated herein by reference.
[0042] According to an exemplary embodiment, a signaling entity
communicating with a media/message proxy may receive a request to
set up a media path between a presence entity and the media/message
proxy. Alternatively, the request may specify a predetermined
service identifier, and signaling entity may be configured to set
up a media path upon detecting such an identifier in a request.
Thus, according to an exemplary embodiment, a signaling entity (a
server or a SIP proxy server) may be configured to receive from a
presence entity a request to establish a media pathway.
Responsively, the signaling entity may authorize the request using
information specified in the request and local presence data
available to the signaling entity. Then, if the request is
authorized, the signaling entity may establish the media path. As
will be describe in greater detail below, the signaling entity may
access a message dispatch facility that is configured to authorize
requests, and the message dispatch facility may authorize the
request. Further, the request to establish the media path may
include a request to interconnect a plurality of pre-established
data paths between a plurality of presence entities and a media
proxy such as the conference server described in greater detail in
the U.S. patent application Ser. No. 10/021,171, herein
incorporated by reference. Alternatively, the signaling server may
pre-establish the media path between the presence entity and the
conference server.
[0043] In such an embodiment, upon receiving such a request, the
signaling entity may authorize the request using local
authorization presence state data available at the signaling
entity, and then send the request to establish the media path.
Alternatively, in the case, where media paths are pre-established
between two presence entities and the media-message proxy, the
signaling entity, upon authorizing a request from one of the
entities, may request the media/message proxy to bridge the media
paths between the two presence entities.
[0044] The media/message proxy provides an additional benefit when
SIP user agents are configured behind Network Address Translators
(NATs). NATs are used to either hide a client's IP address from the
global IP network, or provide global connectivity to a client
device which is configured with only a local IP address behind a
router; e.g. in a Local Area Network. This would be a typical
configuration for SIP UAs in an IP-based PBX system, for example.
Another application is where a service provider uses NATs to hide
the IP addresses of SIP UAs in order to help prevent the theft of
service. When two SIP UAs are each behind different NATs, signaling
for call setup can become cumbersome since two NATs must be
traversed. This leads to numerous possible configuration scenarios
that must be handled by the end-to-end protocols. By locating the
media/message proxy in the service provider's network, any given
SIP UA need only traverse a single NAT (if present). The bridge
between SIP UAs for media and messages is provided by the
media/message proxy, thus, eliminating the complications of
double-NAT traversal.
[0045] In the proposed architecture, two classes of user presence
states are defined: user-specified and facility-specified.
User-specified states are the states to which a user (or a presence
entity acting on behalf of a user) may request to be put in. For
example, the user-specified states may include: an offline state,
an online/available state, an online/unavailable_announce, and an
online/unavailable_hide, for example. It should be understood that
additional user-specified states are also possible, including those
states that may be part of other descriptions of network presence.
Facility-specified states include states that may be associated
with state-machine aspects of presence function implementation. For
example, a generic state, such as a pending state, may be
introduced to help indicate where a user-specified state-change
request is being processed, but not yet completed. The actual
number of states that may be regarded as pending is dependent upon
the implementation. Other facility-specified states are also
possible.
[0046] The presence elements maintain user presence states in the
user presence state data resource, which is managed by the user
presence state facility that will be described in greater detail
below. Additional user presence states beyond the given examples
may be added to the user presence state data resource. Service
requests to the presence entities include identifying information
about the user that places the request (the requester). The
identifying information, among other possible parameters, may
include a user's Presence ID, and may also include the user's User
Account ID.
[0047] Any service request that applies to information about any
other user besides the requester may depend upon the other user's
(or users') Presence ID(s) only so that the requester is not
required to have knowledge of other users' User Account IDs (and
may be prevented from having such knowledge for security/privacy
reasons).
[0048] Signaling and call control functions may typically require
more information than simply a Presence ID. The presence elements
may be able to obtain such information, e.g., from an
Authorization/Authentication database, the embodiments of which
will be described in greater detail below. For example, one or more
presence elements may be configured to translate a Presence ID into
sufficient routing information to contact a SIP Proxy Server
responsible for the user associated with the Presence ID. At the
same time, end users may communicate using Presence IDs only, with
no knowledge of the routing information.
[0049] According to exemplary embodiments, a Presence ID may
support a multiplicity attribute that specifies how many users are
associated with the ID. The multiplicity attribute may be defined
using two values: an individual or a group. An individual Presence
ID is associated with a single user, and all functions and
operations that use or depend on an individual Presence ID apply to
that single user. For example, sending a voice message to a user
associated with a Presence ID. A group Presence ID allows more than
one user to be associated with the ID. All users associated with a
given group Presence ID may be referred to as the presence user
group, and all functions and operations that use or depend on the
group Presence ID may apply to all users belonging to the presence
user group. It should be understood that some functions may only
allow one active user from the presence user group at a time; e.g.,
a sender of a voice message. Others may allow multiple simultaneous
users; e.g., receivers of a voice message.
[0050] Management of individual Presence IDs, group Presence IDs,
and presence user groups may be accomplished through a provisioning
system that may also be used for provisioning and updating other
aspects of user profiles.
[0051] Before describing specific implementations of presence
services within the context of the proposed architecture that will
be later described in greater detail, basic functions and services
of the presence functions are briefly described in Table 1.
TABLE-US-00001 TABLE 1 Function or Service Description Register SIP
Registration of a user agent with a SIP proxy server Access of
Authorization/Authentication Database retrieves presence-related
information from user profiles Change State to Go online with a
presence service Online/Available Allow subscriptions to a presence
state (via a Presence ID) Enable subscribers to send messages to
the Presence ID Notify presence to authorized subscribers Notify
availability to receive messages from authorized dispatchers (users
authorized to send messages to the Presence ID) Change State to
Online/ Go online with a presence service Unavailable_Announce
Allow subscriptions to you a presence state (via a Presence ID) Do
not enable subscribers to send messages to the Presence ID Notify
presence to authorized subscribers Notify unavailability to receive
messages from authorized dispatchers Change State to Online/ Go
online with a presence service Unavailable_Hide Do not allow
subscriptions to a presence state (via a Presence ID) Do not enable
subscribers to send messages to a Presence ID Do not notify
presence to authorized subscribers Do not notify availability to
receive messages from authorized dispatchers Change State to
Offline Go offline with presence service Disable subscribers from
sending messages to Presence ID Notify any subscribers Subscribe
Request to subscribe to one or more users' presence state via their
Presence IDs Solicit Request the current presence states of one or
more users via their Presence IDs Optionally request a subscription
to presence states of the same users Unsubscribe Cancel
subscription to presence state of one or more users via their
Presence IDs Deregister Cancel SIP registration of user agent with
a SIP proxy possible update of accounting information for
presence-based services in a user profile Change Subscriber Change
the permission of a user's or users' Authorization subscription(s)
to a presence state; e.g., services that those users can use to
contact your Presence ID, deauthorizing would-be dispatchers
Dispatch Message Dispatch a message to one or more users using
their Presence ID Initialize Presence-based Service-specific
actions for initialization/start- Service up of presence-based
services Authorization request Presence function directs a request
to a from another user Presence ID from another user for
authorization related presence-based services, e.g., permission to
subscriber to the Presence ID, permission to send messages to the
Presence ID, permission to learn a current state of the Presence
ID, request to modify permissions associated with a subscription to
the Presence ID.
[0052] According to one exemplary embodiment, presence services are
implemented using five data resources and three presence function
facilities. It should be understood that decomposition of the
presence functionality is only exemplary and different embodiments
are possible as well. A data resource refers to a logical grouping
of data that is used by some presence function facility in order to
carry out a specific task or tasks. Multiple data resources might
represent different views or subsets of a single database, each
data resource existing only as a logical entity. Alternatively,
each data resource might be implemented as a distinct database, or
as a data structure within the context of the facility that uses
it.
[0053] Further, data resources refer to user-related information
accessed by the three presence function facilities in order to do
their jobs. The data resources may be maintained as part of the
authorization database, or as application-specific data structures.
Much of the static and semi-static information contained may
duplicate information already contained in the authorization
database, so extending the authorization database for the presence
function could be a reasonable approach. However, performance
considerations may favor memory-resident, application-specific data
structures.
[0054] In addition to the data resources, there are also transient
resources. These are created and consumed by the functional
facilities as needed, and may be derived from the data resources
and/or other information in the user profiles.
[0055] The five data resources include, but are not limited to,
user presence state data resources, authorized subscribers lists,
current subscriber lists, authorized dispatchers lists, and desired
watch lists. In one embodiment, data resources may be organized on
a per-presence entity basis, so that each presence entity is said
to "own," or be the "owner" of, a persistent instance of one of
each of the data resources, with the exception of the authorized
dispatchers list, i.e, a list owned by one presence entity that
contains other presence entities that are authorized to dispatch
messages to the list owner. A given presence entity at a given time
may own zero, one, or multiple authorized dispatchers lists,
depending upon whether or not any authorized dispatchers exist for
the given presence entity, and at which SIP Proxies they are
registered, the embodiments of which will be described in greater
detail below.
[0056] It should be understood that the term "list" is a logical
description of the data resource, and does not imply any
requirement regarding implementation. Similarly, the distinction of
five data resources is a logical organization made to accommodate
the functionality of the three presence function facilities. To the
extent that specific information is duplicated across categories,
the actual implementation of the data resources may combine
databases and/or data structures so long as the required
functionality is supported and performance requirements are
met.
[0057] As described below, some of the data resources include
global data that are maintained centrally, while others comprise
local data that are maintained locally (and are distributed). In
the exemplary embodiments described in greater detail below, the
data resources are assumed to be associated with specific network
components. However, it should be understood that other
implementations are also possible. That is, the distinction between
global/central and local/distributed is logical, and not intended
to limit the actual implementation of the data resources. For
example, a centrally maintained, global data resource may actually
be implemented in a distributed database architecture using
multiple servers and database replication/synchronization.
[0058] In addition to these resources, there are other list-like
resources that are transient, may be created and consumed as needed
by the functional facilities. These may include an authorized watch
list, i.e., a presence entity's list of willing notifiers (presence
entities who are subscribed to by one or more subscribers and
agreed to be notifiers and send notifications to subscribers) and a
cancellation list, i.e, a list of subscriptions that a subscriber
would like to cancel, where the subscriber is a presence entity who
currently has subscriptions (where a subscription is a persistent
request by one presence entity to be notified of changes in
presence state of another presence entity) to the presence entities
in the list.
[0059] As mentioned above, the exemplary system for distributed
presence services uses three functions including a user presence
state facility, a notification request facility, and a message
dispatch function. As described in greater detail below, these
facilities provide combinations of global/central functionality and
local/distributed functionality. In the exemplary descriptions
below, they are assumed to be associated with specific network
components. As with the data resources, it should be understood
that other implementations are possible. Further, distinctions
between global/central and local/distributed are logical, and not
intended to limit the actual implementation of the functional
facilities.
[0060] FIG. 2 is a block diagram illustrating a reference
architecture 200 showing the relationship between data resources,
functional facilities and network components. The functional
facilities are represented as rectangles and labeled appropriately.
FIG. 2 illustrates local presence elements illustrated with two SIP
proxy servers 202 and 208 communicating via a network 214 with a
centralized presence element illustrated with a central server 216.
The central server 216 may be an AAA server; however, different
embodiments are possible as well. The central server 216 includes a
user presence state unit 218, a notification request unit 220 and a
message dispatch unit 222. Each of these units includes or has an
access to data resources represented with databases: a state
database 224, a subscriber database 226, and a dispatcher database
228.
[0061] According to an exemplary embodiment, the global data
resources include user a presence state list that may be stored in
the user state database 224, a desired watch list, an authorized
subscriber list, and a current subscriber list that may be stored
in the subscriber database 226. FIG. 2 illustrates an instance of
distributed elements, the message dispatch unit 222 with the
dispatcher database 228 at the central server 216. However, it
should be understood that the message dispatch facility is a
distributed and local facility, and placing the message dispatch
unit 222 at the central server 216 may accommodate an embodiment,
in which one or more SIP proxy servers do not have their own
dispatcher elements.
[0062] FIG. 2 illustrates the distributed facility of message
dispatchers at the two SIP proxy servers 202 and 208 including
message dispatch units 206 and 212 having access to databases 204
and 210 including authorized dispatchers list, where an authorized
dispatcher is a presence entity authorized to dispatch (or send)
messages to another presence entity. In the network architecture
200, the centralized elements of the presence services are
associated directly with the central server 216 or an authorization
server, while the distributed elements are associated with the SIP
proxy servers 202 and 208.
[0063] According to exemplary embodiments, the centralized elements
at the central server 216 manage and use data resources that are
global in scope, and provide centralized services. The information
contained in the global data resources is closely related to that
in an authorization database, so that an AAA Server may host these
presence function elements. However, it should be understood that
the centralized elements could also be implemented in a distinct
central server. Similarly, the local data and distributed
functionality of the presence function are tied to the point of SIP
registration of the user agent that represents the user to the
network; i.e., the SIP proxy server. For this reason, as well as
others detailed below, each SIP proxy server is associated with an
instance of the distributed component of the presence services.
However, it should be understood that the actual implementation in
terms of hardware platforms and detailed software decomposition of
the distributed presence services and SIP proxy server functions is
not meant to be limited by this logical construction, and different
or equivalent embodiments are possible as well.
[0064] FIG. 3 is a block diagram illustrating distributed presence
service functionality at three distinct SIP proxy servers. FIG. 3
illustrates three SIP proxy servers, labeled as a SIP proxy 1 302,
a SIP proxy 2 304 and a SIP proxy N 306. In the exemplary diagram,
data resources are illustrated as rectangles with curved sides or
corners, and also labeled according to the terminology introduced
above. The arrows labeled "Read/Write" or "Read" in FIG. 3 indicate
a relationship between the facilities and data resources. The
arrows labeled with "Rqst" and "Response" represent pseudo-APIs
associated with the facilities. It should be understood that FIG. 3
is intended to illustrate services of the facilities in a generic
sense, without implying any limitations to actual implementation.
Further, these pseudo-APIs do not imply anything about the
underlying data transport.
[0065] As described above, each presence entity is the "owner" of
instances of the data resources. Individual owners are identified
by Presence IDs (an identity of a presence entity that is used for
the purpose of presence-based services), which, in FIG. 3, are
labeled as PresID A, PresID B, etc., where A, B, . . . , is
intended to designate a globally unique identifier. It should be
understood that depending upon network configuration, global
uniqueness may require inclusion, e.g., of domain names in the
identifiers. Each SIP proxy server includes a message dispatch
facility illustrated as 308, 310 and 312 that have access to
distributed data resources including authorized dispatcher
lists.
[0066] While for global or centralized data resources, a presence
entity owns a single instance of a user presence state, such as in
an authorized subscribers list, a desired watch list, and a current
subscribers list, the same presence entity may be associated with
multiple authorized dispatchers lists, as illustrated in reference
to PresID A, for example. In FIG. 3, PresID A has two authorized
dispatchers lists: one on the SIP Proxy 302, and another on the SIP
Proxy 304. The PresID a may also have a third authorized dispatcher
list associated with a centralized instance of the message dispatch
facility, where the PresID A has authorized dispatchers who are
registered at a SIP proxy servers 1 and 2, as well as some SIP
proxy server which has no message dispatch function. The absence of
an authorized dispatchers list for PresID A at the SIP proxy server
306 implies that there are no authorized dispatchers for PresID A
registered at that SIP proxy. That is, the existence of a local
authorized dispatchers list at a particular SIP proxy for some
online user is dependent upon authorized dispatchers for that user
being registered at that SIP proxy, and the user does not have to
be registered at that SIP proxy. Similarly, PresID B has authorized
dispatchers lists at the SIP proxy 304 and the SIP proxy 306.
[0067] Communications between a message dispatch element and its
associated SLP proxy may be achieved using pseudo-APIs or other
methods. The SIP proxy servers 302, 304 and 306 provide
communication links to the centralized server, such as an
authorization server, using standard or proprietary protocols, such
as RADIUS or 3Q, for instance. This link is used for communications
between the message dispatch units and the centralized facilities,
as well as any required access to the authorization server and its
database.
[0068] The message dispatch facility instance, together with its
associated authorized dispatchers lists, at each SIP Proxy is
independent from that at any other SIP Proxy. Further, each
authorized dispatchers list is constructed from information
available to either the centralized piece of the presence function
or the authorization server. Therefore, it is possible to replace a
failed SIP Proxy with a redundant backup without the need to
communicate any related information or notices to any of the other
SIP Proxies or their associated media data functions units, or to
request any related information from them. Thus, if a SIP Proxy
fails, all information required to recover its registration
information and its authorized dispatchers lists can be obtained
from the authorization server and the centralized components of the
presence services. A backup can be activated and made operational
with minimal impact on the overall system performance. None of the
other SIP Proxies or message dispatch elements need to be aware
that any failure event occurred, thus, simplifying failure
recovery.
[0069] According to an exemplary embodiment, an authorized
dispatchers list is a per-presence entity list of current
subscribers who are authorized to dispatch messages to the owner of
the list. The list also contains current contact information for
the owner of the list. Lists may exist for owners who are currently
online and for whom one or more online current subscribers exist.
Subscribers in the list are referred to as authorized dispatchers,
or just dispatchers. Although each list has an owner, list creation
and maintenance is invoked to facilitate message dispatch by
dispatchers to the owner of the list. As a result, an online
presence entity may be the owner of multiple authorized dispatchers
lists if dispatchers to the multi-list owner are registered at
different SIP Proxy servers, as illustrated in reference to PresID
A in FIG. 3, i.e., the lists are co-located with the message
dispatch facility that support would-be dispatchers, and not
necessarily with the message dispatch facility that supports the
owner of the lists. Therefore, the scope of authorized dispatchers
resource is local, and the list existence supports the message
dispatch facility associated with SIP Proxy server of current
subscribers who are authorized to dispatch messages (i.e.,
authorized dispatchers) to the owner of the list.
[0070] Further, each authorized dispatcher entry is identified
using Presence IDs that identify both the owner and list entries
(authorized dispatchers to the owner). For each online presence
entity (Presence ID), zero or more lists may be maintained of all
authorized dispatchers. An authorized dispatcher is a presence
entity (Presence ID) other than the owner of the list who is a
current subscriber to the owner of the list and is authorized to
dispatch messages to the owner of the list. If no authorized
dispatchers currently exist for a given presence entity, then there
may be zero authorized dispatchers lists for that presence entity
(existence of one or more lists even if no dispatchers exist may be
possible if there is a delay between dispatchers logging off and
deletion of the lists).
[0071] There may be additional restrictions and/or conditions that
apply to attributes of the message dispatching function for each
authorized Dispatcher's Presence ID in a given list. For example,
the restrictions may specify what service(s) may dispatch messages
to the owner of the list, etc. The restrictions/conditions
associated with a given dispatcher may be the same as those in the
current subscribers list.
[0072] In addition, each list contains contact information for the
owner of the list. This information may include the owner's URI, IP
address, and SIP Proxy server. Which contact information is
included will depend upon the service(s) that is (are) supported.
For example, for IP Intercom service, the contact information is an
IP address and port on a conference server to which the owner of
the list is connected (has an RTP connection).
[0073] According to an exemplary embodiment, message dispatch
facility elements may access the authorized dispatchers lists to
read and write to the lists. Further, each instance of message
dispatch from one online presence entity to another is first
authorized by the message dispatch facility unit. The authorized
dispatchers list is intended to streamline the authorization
process by providing a local subset of the information required for
authorization. Locality refers to the message dispatch facility
unit that services the sender's dispatch request. The list is also
is intended to facilitate the distributed instances of message
dispatch facility units by providing the required information to
the possibly multiple (distributed) message dispatch facilities
that span multiple dispatchers who are registered at multiple SIP
Proxy servers.
[0074] In this distributed architecture, a message dispatch
facility instance is placed in each SIP Proxy server, and dispatch
requests are processed by the message dispatch facility local to
the SIP Proxy at which a dispatcher is registered. Since different
dispatchers associated with the same given presence entity may be
registered at different SIP Proxy servers, the different local
message dispatch facility may have an authorized dispatchers list
for that same given presence entity. Only message dispatch
facilities with at least one dispatcher for a given presence entity
will maintain an authorized dispatchers list for the given presence
entity. As new dispatchers for a given presence entity come online
at a specific message dispatch facility, they will either be added
to a newly-created list for the given presence entity (if they are
the first dispatcher for the presence entity at the message
dispatch facility), or will be added to an existing list at the
message dispatch facility. Once all dispatchers associated with a
given presence entity and registered at the same SIP Proxy go
offline, the local message dispatch facility serving those
dispatchers may delete the given presence entity's authorized
dispatchers list. Note that implementation considerations may favor
a (configurable) delay before deleting the list.
[0075] An instance of a distributed message dispatch facility may
also be included in the centralized presence function. Its purpose
is to allow participation of SIP Proxy servers, which do not
implement a distributed message dispatch facility. Such SIP Proxy
servers would be required to forward dispatch requests to the
centrally located message dispatch facility. Implementation of the
central message dispatch facility in the hybrid model need not be a
copy of the distributed implementation used on the SIP Proxy
servers. However, different embodiments are possible as well.
[0076] According to an exemplary embodiment, message dispatch
facilities 308, 310, 312 dispatch messages from one user to one or
more other users, and manage the authorized dispatchers lists. As
mentioned above, the message dispatch facility is the distributed
part of the presence function and is used to distribute the
traffic-intensive part of Presence-based services among the SIP
proxy servers to which presence users register. That is, in
contrast to subscription requests and state change notifications,
which are relatively infrequent, requests for message dispatches
will be quite frequent. Since each and every message dispatch
request should be authorized, enabling the SIP Proxy servers of the
requester to service the dispatch requests eliminates the potential
load and bottleneck from the centralized piece of the presence
function.
[0077] The message dispatch facility is a facility that is local to
each SIP Proxy server. At each SIP Proxy server, a message dispatch
facility instance manages a local set of authorized dispatchers
lists: a set of dynamic data resources which contain contact
information for would-be message recipients, and which associate
each would-be recipient list of authorized dispatchers who are
registered with the local SIP Proxy server. That is, a given
would-be recipient owns an authorized dispatchers list at each SIP
Proxy, which has registered users who are authorized dispatchers
for that would-be recipient. Each authorized dispatchers list at a
given SIP Proxy server is dynamic in the sense that list entries
(i.e. authorized dispatchers) are added and deleted as a result of
a subscription cancellation by an authorized dispatcher, an
authorized dispatcher going Offline and/or deregistering with the
SIP Proxy, or a notifier request to de-authorize a given authorized
dispatcher, for instance.
[0078] In addition, a given message dispatch facility may have no
authorized dispatchers list for a given notifier if no authorized
dispatchers for that notifier registered at the local SIP Proxy. An
authorized dispatchers list for a given notifier may be created at
a particular MDF when at least one user registered at the local SIP
Proxy becomes an authorized dispatcher to that notifier. The list
may be deleted when all previously existing authorized dispatchers
to that notifier are deleted from that notifier's list. (Depending
upon implementation considerations, there may be a delay between
the time the list becomes empty and deletion of the list).
Similarly, when a user goes Offline, all message dispatch
facilities, which were maintaining an authorized dispatchers list
for that user, are notified and may delete their respective
lists.
[0079] Some Dispatch requests may comprise start/stop pairs (not to
be confused with the Rqst/Rsp transaction pair) if the actual
message data are sent as a media stream (e.g., using RTP). This is
the case, for example, with IP Intercom (U.S. patent application
Ser. No. 10/021,171, incorporated herein by reference), which uses
one Dispatch request to set a media channel active prior to the
start of media flow, and another to set the media channel to
inactivate once the media flow has ended. These paired Dispatch
messages use an optional Start parameter in the initial request,
and a Stop parameter in the closing request; the Stop is required
if the request used the optional Start.
[0080] The message dispatch facility may have actions and tasks
associated with initialization of Presence-based services. The
message dispatch facility may include a generic service
initialization parameter to accommodate such operations. The
pseudo-API of the message dispatch facility supports two
request-response pairs: Update_Rqst and Update_Rsp; and
Dispatch_Rqst and Dispatch_Rsp. Update_Rqst is used to request an
update to the local authorized dispatchers lists, as well as
requesting service initialization; and Dispatch_Rqst is used to
dispatch a message. Table 2 lists pseudo-APIs that may be used on
each message dispatch facility.
[0081] As with the introduction of the functional facilities, these
pseudo-APIs help organize the description of the information and
actions required in order for a given facility to deliver a
service. Again, there are no implied requirements regarding
implementation of actual APIs other than support of the
functionality and information exchanged between entities.
Additional APIs may be added, and the ones listed may be modified
as necessary for achieving required functionality. Further, no
assumptions or restrictions are placed upon external interfaces or
transport protocols, which interconnect infrastructure components
that implement the presence function; e.g., the authorization
server and the SIP Proxy servers. In the case of the centralized
portions of the presence function, different facilities may
communicate with each other internally by way of the pseudo-APIs
without ever encountering any external interfaces.
[0082] It should be understood that by illustrating an exemplary
set of APIs, no requirement is implied on the number or format of
parameters used in the actual implementation, and additional APIs
may be added. The descriptive names given for the inputs and
outputs are suggestive of their purpose only. Additional
parameters, which may be related to implementation, such as
sequence numbers for matching responses to requests, are not
considered in this document.
TABLE-US-00002 TABLE 2 Name Description Use Related UPSF Actions
Update Inputs fromPres_ID Presence ID of Used on all Identifies the
requester for requester or requests Subscription setup and would-be
sender cancellation; if request is not identifies would-be
initiated by sender for other types of fromPres_ID requests
toPres_ID Presence ID of Used on all Presence ID of user who
would-be requests owns Authorized recipient; may be Dispatchers
List to which a list this request applies; if this is a
Subscription setup, then fromPres_ID is added as an Authorized
Dispatcher to the list (a new list is created if fromPres_ID is the
first Authorized Dispatcher at this MDF); if this is Subscription
cancellation, then fromPres_ID is deleted from the list; if this is
toPres_ID going Offline, then toPres_ID identifies the list owner,
and the list may be deleted; if this is toPres_ID deauthorizing a
previously Authorized Dispatcher, then toPres_ID identifies the
list owner and fromPres_ID is removed from the list. P_srvc_ID
Presence-based Used on all Controls any service-specific service
associated requests aspects of request to the with this request MDF
DspchList_update Indicates request Used on all Some actions
include: for update of requests for Add fromPres_ID to Authorized
updates to the Authorized Dispatchers List Dispatchers List
Authorized of toPres_ID; for toPres_ID Dispatchers List remove
fromPres_ID of user from list; identified in update contact
toPres_ID. information for toPres_ID. P_srvc_init Service Used to
indicate Specific actions depend upon initialization that MDF needs
the service parameter to perform some service- related
initialization tasks Update Outputs fromPres_ID Presence ID of Used
on all Identifies the requester for original requester responses
Subscription setup and or would-be cancellation; sender identifies
would-be sender for other types of requests toPres_ID Presence ID
of Used on all Presence ID of user who would-be responses owns
Authorized Dispatchers recipient; may be List to which this request
a list applied P_srvc_ID Presence-based Used on all Provides
service-specific service associated responses return information
for with this request service initialization Status Generic status
As needed Various, depending on parameter details init_complete
Indicates service- Used to indicate Specific actions depend upon
related that MDF the service. initialization is actions for
complete; specific service init actions initialization are depend
on service complete Dispatch Inputs fromPres_ID Presence ID of Used
on all Identifies the user who wants requester requests to send a
message toPres_ID Presence ID of Used on all The MDF checks to see
if intended message requests fromPres_ID is an recipeint(s); may
Authorized Dispatcher to be a list toPres_ID by checking the
Authorized Dispatchers List of toPres_ID; if toPres_ID is a list,
then the MDF checks for each list entry. msg Presence-based Used on
all Message to be sent. service associated requests Interpretation
may depend with this request upon specific Presence-based service.
[start] Optional start Used on Depends upon specific parameter
requests which service. Actions for start of must be paired sending
begin with start with a stop parameter [stop] Optional stop Used on
Depends upon specific parameter requests which service. Actions for
stop of must be paired sending begin with stop with start parameter
Dispatch Outputs fromPres_ID Presence ID of Used on all Identifies
the original original requester responses requester toPres_ID
Presence ID of Used on all Identifies Presence ID(s) to message
responses whom dispatch actions were recipient(s); may applied. be
a list Status Status of request
[0083] FIG. 4 is a block diagram illustrating an exemplary
architecture of centralized elements of the presence services.
According to an exemplary embodiment, centralized facilities, which
may be implemented on the Auth Server or a distinct server, include
a user presence state facility ("UPSF") 402, a notification request
facility ("NRF") 404, and a message dispatch facility ("MDF") 408.
It should be understood that the intercommunication between those
facilities may be handled internally using pseudo-APIs or other
methods. Some or all of the data that comprises the various data
resources may be stored as part of the authorization database. For
example, the authorized subscribers list may be part of a user
profile. Thus, methods may exist to interface software that
constructs the data resources and the authorization database, and
an SQL could be used, for example. If the centralized facilities
are implemented on a distinct server, access to the authorization
database may be done using additional standard or proprietary
protocols, such as RADIUS, which is an example of a standard
protocol, or 3Q, which is an example of a proprietary protocol.
[0084] According to an exemplary embodiment, the UPSF 402 provides
user presence state tracking. The UPSF manages the user presence
state data resource. It has read/write access to a user presence
state data resource 408, and acts in response to changes in state
and requests to report state. The UPSF 408 also has read access to
a desired watch list data resource 410 including desired watch
lists, i.e., a presence entity's list of desired notifiers
(presence entities to which the presence entity would like to
subscribe to).
[0085] The UPSF 402 tracks the presence state of each user through
management of the user presence state data resource 408, and makes
that information available to other functions as required. The
pseudo-API of the UPSF 402 supports a single request-response pair:
Update_Rqst and Update_Rsp. Update_Rqst is used either to inform
the UPSF 402 of a change of presence state for a specific user, or
to request the current presence state of a specific user. Inputs
passed in Update_Rqst will be used by the UPSF 402 to determine its
specific actions. Update_Rsp is used to inform the requester of the
results of the request, as well as to pass any required output.
Table 3 illustrates a set of pseudo-APIs that may be used on the
UPSF 402. It should be understood, as explained in reference to
Table 1, that the illustrated APIs are only exemplary, and
different embodiments are possible as well.
TABLE-US-00003 TABLE 3 Name Description Use Related UPSF Actions
Inputs fromPres_ID Presence ID of Used on all Identifies the
requester requester requests toPres_ID; or Presence ID(s) Used on
For Pull request, retrieve DesiredWatch_list that is target of Pull
requests; UPS associated with this request; may be a or Presence
ID; or list (Desired else, used to else, pass to NRF as Watch List)
override Desired Watch List default Desired Watch List newState
User-specified Used on all request Current Subscribers state
requested state-change List from NRF requests Request Authorized
Watch List from NRF for Offline-to-Online requests update UPS to
newState or Pending depending upon request and inputs P_srvc_ID
Presence-based Used on all Controls service-specific service
associated requests aspects of request; may be with this request
passed to NRF in NRF service request if applicable Pull Indicates
request Indicates a If request is granted by the for immediate
Soliciter NRF, the UPSF retreives the status on state(s)
Subscription current state of the of all Desired request; i.e.,
Notifier(s) Notifiers when requester doesn't want to wait for
change in status of Desired Notifier(s) init_complete Indicates
service- Used for UPSF updates requester's related requests that
from Pending to newState initialization is result in once it
receives indication complete; specific Pending state that
initializations related to init actions until newState are
complete. depend on service initialization is complete; signals
that conditions for newState are valid Outputs fromPres_ID Presence
ID of Used on all Identifies the original original requester
responses requester Cur_Subscriber Current Informs the Passed to
UPSF from NRF; Subscribers List requester of passed to requester in
UPSF which users response to requester must be notified of state
changes AuthWatch_list; Authorized Provides the Passed to UPSF from
NRF; or toPres_ID Watch List; or requester's passed in UPSF
response to single Willing Authorized requester; single Notifier in
Notifier Watch List; or case of request for single single Willing
Subscription Notifier P_srvc_ID Presence-based Used on all Matches
service of input service associated state-change request; may
include with this request requests parameters from the system
Status Current state of Returns current Used by UPSF to pass
Notifier(s) state of current state of Notifiers Notifier(s) to
requester
[0086] The user presence state resources 408 managed by UPSF 402
are used to store the current presence state of each user. The
scope of the presence state resources is global, i.e., data for all
users are maintained centrally and is global in scope. According to
an exemplary embodiment, for each presence entity, identified by a
Presence ID, this resource records the current presence state. The
presence state of any presence entity may be both read (read
access) and updated (write access) by the UPSF 402, as illustrated
in FIG. 4. All presence entities are represented in this resource
as long as they are in one of the allowed user presence states
(which includes Offline).
[0087] As mentioned above, the UPSF 402 also manages the desired
watch list data resources 410. A desired watch list data resource
is a per-presence entity list that specifies which other presence
entities the owner of the list would like to subscribe to; i.e.,
which other presence entities the owner of the list desires to
watch for presence state changes. List entries are referred to as
desired notifiers. Further, list entries identify both the owner of
the list and list entries (desired notifiers of the list owner).
The lists may be stored as part of the user profile, and used by
default if a request does not supply a list explicitly. That is, if
a service request to the NRF 404 from the UPSF 402 requires the
desired watch list, and the list has not been explicitly supplied
in the upstream request to the UPSF 402, then the UPSF 402 may
access the user profile to obtain a default list.
[0088] For each presence entity, identified by Presence ID, the
desired watch list is used when no the presence entity first
requests to go Online to indicate to the NRF 404 to which presence
entities the requester would like to subscribe. The list is
filtered according to the authorized subscribers list of each
desired notifier in order to generate an authorized watch list. The
requester may explicitly send a desired watch list to the presence
function, or omit it and let the UPSF 402 access the presence
entity's default list. The owner of the default list may modify the
default list contents in user profile through the provisioning
server. All presence entities may have an associated desired watch
list regardless of their current user presence state.
[0089] The NRF 404 provides subscription and notification
functions. The NRF 404 manages current subscribers lists data
resource 412. The NRF 404 also has a read access to authorized
subscribers lists 414 associated with each user. Write access to
each user's authorized subscribers lists is made available to the
respective user via the provisioning server.
[0090] Subscription requests are accompanied by the Presence IDs of
one or more desired notifiers. The requesting user may supply the
Presence IDs, or the UPSF 402 may retrieve the requester's desired
watch list on behalf of the requester. The NRF 404 may filter
requests using the authorized subscribers lists of the desired
notifiers in the subscription request to determine the authorized
watch list. Granted subscription requests cause the NRF 404 to
insert the requester's Presence ID in the current subscribers lists
of all willing notifiers. The NRF 404 also returns the requester's
current subscribers list for requests that correspond to changes in
user presence state.
[0091] Subscription requests can come directly from a user (or
user's agent), or from the UPSF 402 as part of state-change
request. For example, when a user first goes Online, a request for
subscription to all of the user's desired notifiers is sent to the
NRF 404. There are two types of subscription request: a watcher
request and a solicitor request. Watcher requests are those, for
which a requester would like to be alerted upon future changes in
state of the notifier(s). Solicitor requests are those, for which a
requester would like an immediate report of the current state of
the notifier(s).
[0092] The pseudo-API of the NRF 404 supports two request-response
pairs: Subscribe_Rqst and Subscribe_Rsp; and Unsubscribe_Rqst and
Unsubscribe_Rsp. Subscribe_Rqst is used to request a Subscription,
and Unsubscribe_Rqst is used to cancel a Subscription. Table 4
lists an exemplary set of pseudo-APIs that may be used on the NRF
404.
TABLE-US-00004 TABLE 4 Name Description Use Related UPSF Actions
Subscribe Inputs fromPres_ID Presence ID of Used on all Identifies
the requester requester requests toPres_ID or Presence ID that Used
on all Filter request against DesiredWatch_list is target of
requests for Authorized Subscribers request; Watcher and Lists of
all Desired Notifiers if list, then more Solicitor to identify all
Willing than one Subscriptions Notifiers; Subscription is insert
requester's requested Presence ID into Current Subscribers Lists of
all Willing Notifiers; generate Authorized Watch List as a from
list of Willing Notifiers newState User-specified Used on all
Access and return the state requested state-change requester's
Current requests; signals Subscribers List; that the NRF may be
other actions accesses the depending upon the new requester's and
old states. Current Subscribers List P_srvc_ID Presence-based Used
on all Controls any service-specific service associated requests
aspects of request to the NRF with this request Pull Indicates
request Indicates a Same as for Watcher for immediate Solicitor
Subscription request; status on state(s) Subscription passed to
UPSF by NRF of all Desired request; i.e., when Solicitior request
Notifiers when requester comes directly to NRF from doesn't want to
user (or user's agent). wait for change a granted Soliciter may
also in status of become a Watcher by default Desired Notifier(s)
Subscribe Outputs fromPres_ID Presence ID of Used on all Identifies
the original original requester responses requester Cur_Subscribers
Current Informs the Passed to UPSF from NRF; Subscribers List
requester of passed to requester in UPSF which users response to
requester must be notified of state change AuthWatch_list;
Authorized Provides the Passed to UPSF from NRF or toPres_ID Watch
List; or requester's after generation of the List; single Willing
Authorized single Notifier in response to Notifier Watch List; or
single Subscription request single Willing Notifier P_srvc_ID
Presence-based Used on all Controls service-specific service
associated requests aspects of request with this request Status
Current state of Returns current Used by NRF to pass current
Notifier(s) state of state of Notifier(s) directly to Notifier(s)
to user when user has made requester direct Solicitor request to
NRF. Unsubscribe Inputs fromPres_ID Presence ID of Used on all
Identifies the original original requester requests requester
toPres_ID or Presence ID that Used on all NRF removes the
requester's AuthWatch_list is target of requests for Presence ID
from the Current request; cancellation of Subscribers Lists of all
if list, then more Watcher and Notifiers identified in input than
one Soliciter Authorized Watch List. cancellation is Subscriptions
This request can only follow requested successful Subscription
request(s); therefore, the Authorized Watch list is known to the
user upon input P_srvc_ID Presence-based Used on all Controls any
service-specific service associated requests aspects of request to
the NRF with this request Unsubscribe Outputs fromPres_ID Presence
ID of Used on all Identifies the original original requester
responses requester toPres_ID or Presence ID that Used on all
Identifies Presence IDs that AuthWatch_list is target input of
responses were subjects of Subscription request; cancellation if
list, then more than one cancellation was requested Status Status
of request
[0093] According to an exemplary embodiment, when the UPSF 402
accesses the requester's desired watch list, the UPSF 402 may pass
this list to the NRF 404 as part of a service request, for
instance. For each entry in the desired watch list, the UPSF 402
accesses the corresponding authorized subscribers list. If the
requester (owner of the desired watch list) is found as an entry in
the authorized subscribers list, then that desired notifier is
identified as a willing notifier (with possible
conditions/restrictions). If the requester is not in an authorized
subscribers list, then that desired notifier is not identified as a
willing notifier. The authorized watch list is then constructed
from the list of all identified willing notifiers.
[0094] In the case when the requester is not an authorized
subscriber of the desired notifier and the notifier is Online, a
dynamic request may be sent to the desired notifier. If the desired
notifier grants permission, then the desired notifier may be
identified as a willing notifier and added to the requester's
authorized watch list. The dynamic request may also include options
for the desired notifier to add the requester to his/her authorized
subscribers list, or just make a one-time grant of permission.
[0095] An authorized watch list is a per-presence entity list that
specifies which other presence entities the owner of the list may
subscribe to; i.e., which other presence entities the owner of the
list is authorized to watch for presence state changes. List
entries are referred to as willing notifiers. The authorized watch
list may be a temporary list, in that it is created by the NRF 404
upon request from the UPSF 402 and consumed by other functional
facilities and/or clients of the presence function. Presence IDs in
the authorized watch lists identify both the owner of the list and
list entries (Willing Notifiers of the owner).
[0096] For a given Presence Entity (Presence ID), the list contains
all other Presence Entities (Presence IDs) who have granted
permission to the owner of the list to subscribe to their presence
(permission may be granted on behalf of a Notifier by an agent who
has access to Notifier's profile information; e.g., the NRF 404
accessing the authorized subscribers list). List entries are
referred to as willing notifiers because permitting the owner of
the list to subscribe to them means willingness to notify the owner
upon changes to their presence state. Associated with each willing
notifier's presence ID in a given list there may additionally be
restrictions and/or conditions that apply to the subscriptions to
notifiers. For a given willing notifier, these
conditions/restrictions are derived from the authorizied
subsrcibers list associated with the Presence ID of the
notifier.
[0097] The current subscriber list resources 412 may include a
per-presence entity list that specifies which other presence
entities are currently subscribed to the owner of the list. List
entries are referred to as current subscribers. Only authorized
subscribers to the owner of the list who are currently online may
be included in this list. According to one embodiment, Presence ID
in each list identifies both the owner and list entries (online,
authorized Subscribers to the owner). Further, for each presence
entity (Presence ID), a list is maintained of all current
subscribers. A current subscriber is a presence entity (Presence
ID) other than the owner of the list who is online, authorized to
subscribe to the owner of the list (i.e. an authorized subscriber),
and has been granted a request to subscribe to the owner of the
list.
[0098] There may be additional restrictions and/or conditions
associated with each Subscriber ID, as described in reference to
authorized subscribers lists. The restrictions/conditions
associated with a given current subscriber may be copied from the
corresponding authorized subscriber entry in the authorized
subscribers list. The different restrictions/conditions applied to
a given authorized subscriber by different presence entities also
apply to the same current subscriber of those presence
entities.
[0099] For each presence entity, identified by a Presence ID, the
current subscribers lists define which online presence entities to
notify when the owner of the list changes user presence state.
Notification of such state changes to any given presence entity in
the list may be subject to restrictions/conditions associated with
that user in the list. All presence entities have an associated
authorized subscribers list regardless of their current user
presence state, although the list may be empty if no other presence
entities have subscribed to the owner of the list.
[0100] As described below, the NRF 404 updates (writes access) the
list on behalf of a list's owner, as well as retrieves (read
access) the list in order to support facilities for notification to
subscribers in the list of state changes of the owner of the
list.
[0101] The authorized subscribers resources 414, also managed by
the NRF 404, include per-presence entity lists that specify which
other presence entities may subscribe to the owners of the lists.
The authorized subscriber list may comprise part of the user
profile information, and a Presence ID in a list identifies both
the owner of the list and list entries (authorized subscribers to
the owner).
[0102] According to an exemplary embodiment, for each presence
entity (Presence ID), a list is maintained of all other presence
entities (Presence IDs) that are authorized to subscribe to the
owner of the list, and the list entries are referred to as
authorized subscribers. Associated with each authorized
subscriber's Presence ID in a given list there may additionally be
restrictions and/or conditions that apply to the subscription.
These may include, but are not limited to time of day, specific
service to which an allowed Subscription applies, list-owner
state-related filters (i.e., user-owner's states acts as a filter
to authorized subscribers privileges with respect to the owner).
The restrictions/conditions associated with a given subscriber are
determined by the owner of the list. That is, different users may
apply different restrictions/conditions to the same Authorized
Subscriber. According to an exemplary embodiment, a provisioning
server may have read/write access capabilities to the authorized
subscribers resources 414.
[0103] Further, in one embodiment, the information in the
authorized subscribers list may be part of the user profile data in
the authorization database in order to support access from the
provisioning server. If the NRF 404 reads that database directly
for its required functionality, then no synchronization may be
used. If, instead, the NRF 404 maintains its own copy of the data,
e.g., in memory-resident data structures, then the user profile
data in the authorization database may be synchronized.
[0104] Further, as described in greater detail above, the
centralized presence function element 400 may also include the
message dispatch facility 406 having a read/write access to
authorized dispatcher resources 416 including authorized dispatcher
lists. The message dispatch facility 406 on the centralized entity
may be used to serve dispatch request from SIP proxy servers that
do not have dispatch functionality.
Functional Description
[0105] In this section a selected set of functions and services,
presented in the form of logic flowcharts and service call flows,
will be used to illustrate the functional description of presence
services according to exemplary embodiments. The set of functions
and services is not intended to describe the full range of presence
services, and only represents fundamental capabilities, and
exemplifies different aspects of the architectural approach.
[0106] The logic flowcharts define actions and decisions that are
taken by the presence function and associated network components in
order to service a specific request or accomplish a related
subtask. It should be understood that the flow charts should not be
viewed as to imply anything about implementation other than which
component is involved. The presence function is decomposed only
into a "centralized component" and a "distributed component," with
no reference to the three facilities described above. At various
steps, input and output data are identified, including the data
resources and items labeled with descriptive names. These are meant
only to indicate information that is key to a particular step or
steps, and are not inclusive of all the data that might be relevant
to that step.
[0107] The service call flows provide examples of how the selected
functions and services could be embodied among the specific network
components and presence functions elements, now including the three
facilities.
[0108] For each of six services of presence service described
below, one or more logic flowcharts are first shown, followed by a
service call flow. The six services presented are: a request to
register and go online (specific case of state change request), a
request to change a presence state (generalization of request to go
Online), a request to subscribe as a watcher, a request to
subscribe as a solicitor, a request to dispatch a message, and a
request to cancel a subscription.
[0109] The logic flowcharts and service call flows included here
are not intended to represent a complete set of cases required for
an actual implementation of presence service. For example, error
cases are not accounted for.
User Request to Register and Go Online
[0110] The request to Register may be a usual SIP Registration
request, and it establishes the SIP Proxy Server to which a user
agent at a client device registers. All subsequent service requests
from the user agent to the system, including presence-related
services, are made through the SIP Proxy. Therefore, part of the
initial processing is an authentication and authorization step. The
request to go online with presence service is a special case of a
general request by the user to change user presence state. Since
presence service is the basis for some high-layer service, such as
instant messaging, the high-layer service may be identified in the
request.
[0111] FIG. 5 is a flow chart illustrating a method for requesting
to register and go online. At step 502, a user agent at a client
device issues a registration request that is sent to a SIP proxy
server. The registration request may include an Account ID of the
user. At step 504, the SIP proxy server receives the registration
request, processes the request, and replies with a registration
confirmation, such as a 200 OK message, to the user agent at the
client device. In one embodiment, the SIP proxy server may
communicate with an AAA server to authenticate the user. The SIP
proxy server may relay the received request including the Account
ID to the AAA server, and the AAA server may authenticate the
request and determine if the user is authorized to access presence
state services.
[0112] When the SIP user agent at the client device receives the
200 OK message, at step 506, the SIP user agent sends a NOTIFY
message to the SIP proxy server, and the NOTIFY message includes a
request to change the state of the user to an ONLINE state. It
should be understood that before the SIP proxy server generates and
sends the NOTIFY message, the SIP user agent first subscribes to
the SIP user agent by sending a SUBSCRIBE message to the SIP user
agent. Responsively, the SIP proxy server may recognize requests
originating from the SIP user agent. According to an exemplary
embodiment, the NOTIFY message may include a Presence ID of the
user, a request for the presence service, and a request to change
the state to ONLINE. Additionally, the NOTIFY message may include a
desired watch list.
[0113] At step 508, when the SIP Proxy server receives the request,
the SIP proxy server relays the request to the centralized
component of the presence services. In one embodiment, the request
may be relayed via the AAA server.
[0114] At step 510, the centralized component of the presence
services receives the request and initializes the state change
request, the embodiment of which will be described in greater
detail in reference to a flow chart in FIG. 6. Once the state
change request is initialized, at step 512, the centralized
component of the presence services sends a response message to the
SIP proxy server. According to an exemplary embodiment, the
response may be relied to the SIP user agent via the AAA server,
and the response message, among other parameters, may include the
Presence ID specified in the request, an authorized watch list, a
current subscriber list, and any other service-related
information.
[0115] At step 514, a distributed component of the presence
function initializes services for the user associated with the
Presence ID. The step of service initialization may depend on
specific presence-based service being requested. For example, the
service initialization may involve setting up RTP connections
between the SIP user agent and another entity.
[0116] At step 516, the distributed component of the presence
services updates local authorized dispatcher lists, the embodiment
of which will be described in greater detail below in reference to
a flow chart illustrated in FIG. 9. The step of updating local
authorized dispatcher lists may include adding or deleting
dispatchers, or creating and deleting dispatcher lists. It should
be understood that authorized dispatchers can be added to a list at
the dispatcher's request, providing authorization has been received
first. Deleting an authorized dispatcher from a given list is done
either at the dispatcher's request as part of a subscription
cancellation, or at the list owner's request as part of some sort
of de-authorization action.
[0117] At step 518, the SIP proxy server generates and sends an
update message to the centralized components of presence functions
via the AAA server, for example. The update message may include the
Presence ID, service-related information, and a parameter
indicating the completion of the initialization process. At step
520, the centralized components of presence services complete the
state change request process, the embodiment of which will be
described in greater detail in reference to a flow chart
illustrated in FIG. 10. According to an exemplary embodiment, the
centralized component may mark the requesting user's state to the
new state.
[0118] At step 522, the centralized presence component sends a
response to the SIP proxy server via the AAA server, and the
response includes the Presence ID. Responsively, at step 524, the
SIP proxy server generates a 200 OK message and sends it to the
user agent ("SIP UA") at the client device. According to an
exemplary embodiment, the 200 OK message may include a watch list.
At step 526, the SIP proxy server generates a notification message
to each current subscriber, and the notification message conveys
that the user associated with the Presence ID is now online.
Additionally, notification messages may be sent to each SIP proxy
server that servers current subscribers. It should be understood
that the notification messages include the Presence ID of the
user.
[0119] At step 528, the SIP user agent may perform service-specific
setup/update actions. The types of steps involved may include
updating user interfaces to display updated information regarding
the service, e.g., display current contacts who are online,
etc.
[0120] FIG. 6 is a flow chart illustrating a method 600 for
initializing a state change request on the centralized component of
the presence services. Specifically, the method 600 provides a
detailed description for step 510 in FIG. 5. At step 602, the
centralized component of the presence services receives a state
change request for a user having a predetermined Presence ID. The
state change request includes the Presence ID of the user, defines
the requested presence services, and specifies a new requested
state. Additionally, the state change request may include a desired
watch list.
[0121] At step 604, the centralized presence component determines
if a new subscription is needed. If so, at step 606, the
centralized presence component determines if a desired watch list
is included in the request. If the desired watch list is not
included, at step 608, the centralized component may retrieve a
desired watch list from a user profile, for instance. At step 610,
the centralized presence component validates the subscription
request, the method of which will be described in greater detail
below in reference to a flow chart in FIG. 7. Upon the validation,
at step 612, the centralized presence component updates the current
subscribers lists of willing notifiers, the method of which will be
described below in reference to a flow chart illustrated in FIG.
8.
[0122] At step 614, service-related initialization actions may be
performed, and, at step 616, the centralized presence component may
retrieve a user's current subscribers list. In one embodiment, the
authorization server may include a centralized-located user's
current subscriber list, and, in such an embodiment, the
centralized presence component may access the authorization server
to retrieve the list. At step 618, the centralized presence
component sends the user's current subscribers list to a SIP proxy
server associated with the subscriber, and the method 600
terminates.
[0123] FIG. 7 is a flow chart illustrating a method 700 for
validating subscription requests on the centralized component of
the presence services. Specifically, the method 700 provides a
detailed description for the step 610 in FIG. 6. At step 702, the
centralized component of the presence services receives a request
to validate a subscription request or subscription requests to one
or more of desired notifiers. According to an exemplary embodiment,
the request includes a desired watch list. At step 704, the
centralized component validates each subscription request in the
desired watch list, and the validation steps are repeated for each
desired notifier in the desired watch list.
[0124] To validate each subscription, at step 706, the centralized
component retrieves an authorized subscribers list of desired
notifiers of each specified watcher. At step 708, the centralized
presence component determines if the Presence ID of the user
requesting the desired watch list is specified in the authorized
subscriber lists of the watchers. If the user's Presence ID is not
in a retrieved list, at step 710, the centralized presence
component determines if a desired notifier is online and if the
notifier accepts subscription requests. If the desired notifier is
not online or does not accept active queries, at step 716, the
centralized presence component does not mark the desired notifier
as a willing notifier. However, if a desired notifier is online and
accepts dynamic queries, at step 712, the centralized presence
entity generates and sends to the desired notifier a subscription
authorization request. At step 714, the centralized presence
component determines if the notifier allows the requested
subscription. If the desired notifier does not accept the
subscription, the method 700 continues at step 716.
[0125] If the desired notifier accepts the subscription, at step
718, the centralized component marks the notifier as a willing
notifier and adds that notifier to an authorized watch list for the
Presence ID. At step 720, when the centralized presence entity
completes validation steps for each desired notifier, the
validation process terminates. Further, at step 722, the
centralized presence component returns an authorization watch list
to the SIP proxy server, and the method 700 terminates.
[0126] FIG. 8 is a flow chart illustrating a method 800 for
updating current subscriber lists of willing notifiers.
Specifically, the method 800 illustrates a detailed description for
the step 612 in FIG. 6. According to one embodiment, the update
actions may include adding a subscriber to a list or deleting a
subscriber from a list. The list owner's corresponding authorized
subscribers list may include conditions and restrictions that apply
to specific subscribers.
[0127] At step 802, the centralized component of the presence
services receives a request to update the current subscriber list
of each willing notifier in the authorized watch list or a
cancellation list. In one embodiment, the request may specify
whether it is an addition request or a cancellation request.
Further, the request may include an authorized watch list or a
cancellation list of the requesting user. At step 804, the
centralized presence component updates the current subscribers of
each identified willing notifier. According to an exemplary
embodiment, the update step is repeated for each willing notifier
in the authorized watch list or the cancellation list.
[0128] At step 806, the centralized presence component determines a
request type. If the request includes a cancellation subscription
request, at step 808, the centralized presence component deletes
the requester (an owner of the cancellation list) from current
subscribers list of this willing notifier. Alternatively, if the
centralized presence component determines that the request is an
addition request to add the requester (an owner of the authorized
watch list) to the current subscriber list of this willing
notifier, at step 810, the centralized component adds the requester
to the current subscriber list of this willing notifier. At step
812, the centralized presence component ends the update process,
and, at step 814, it may return a completion status to the SIP
proxy server of the user.
[0129] FIG. 9 is a flow chart illustrating a method 900 for
updating local authorized dispatcher lists. According to an
exemplary embodiment, this function is performed on the distributed
component of the presence services. Specifically, the method 800
illustrates a detailed description of the step 516 in FIG. 5.
[0130] At step 902, the distributed component of the presence
services, such as a SIP proxy server, receives a request to update
authorized dispatcher lists. In one embodiment, the request may
include a Presence ID, an update request type, the presence service
requested, an authorized watch list, or a cancellation list. At
step 904, the distributed component determines the request type. If
the request is from a willing notifier, at step 906, the
distributed presence component updates an authorized dispatchers
list of the willing notifier, and the update step depends on the
specific request. In one embodiment, the willing notifier may
request removal or modification of privileges of a specified
authorized dispatcher. Alternatively, the distributed component may
delete the list because the willing notifier has gone offline.
Different embodiments are possible as well.
[0131] At step 908, if the request is from a dispatcher, the
distributed component of the presence services updates an
authorized dispatcher list of each willing notifier in the
authorized watch list or in the cancellation list of the requesting
user. It should be understood that this step may be repeated for
each willing notifier in the specified authorized watch list or the
cancellation list. At step 910, the distributed component
determines if the request is a cancellation request. If the request
is not a cancellation request, at step 912, the distributed
component determines if an authorized dispatchers list exists. If
the authorized dispatchers list does not exist, at step 914, the
distributed component creates a new authorized dispatchers list for
this willing notifier including contact information of the
notifier.
[0132] If the authorized dispatcher list exists (step 912), or if
the request is the cancellation request (step 910), at step 916,
the distributed component for presence services may add or delete
user's Presence ID in this willing notifier's authorized
dispatchers list. The Presence ID may be added for a new
subscription or deleted for a cancelled subscription. If the
Presence ID is added, the distributed component may include any
service-related information and/or restrictions/conditions for
adding. At step 918, the distributed component sends a completion
status, and the method 900 terminates.
[0133] FIG. 10 is a flow chart illustrating a method 1000 for
completing state change request on a centralized component of the
presence services. Specifically, the method 1000 illustrates a
detailed description for the step 520 in FIG. 5. At step 1002, the
centralized component of the presence services receives an
indication message that local actions associated with a state
change have been completed. The indication message includes the
Presence ID, presence service-related information, and an indicator
that the state change has been completed. At step 1004, the
centralized component updates user presence state data resources to
indicate that the state has been change to a new state. In one
embodiment, the centralized component may access an authorization
server for a centrally-located copy of the data resource, and may
change the state variable to a new state. At step 1006, the
centralized component may return a completion status.
[0134] FIG. 11 is a call flow 1100 illustrating a method for
processing a user's request to register and go online. FIG. 11
illustrates functional entities involved in the process.
Specifically, FIG. 11 illustrates a SIP user agent A ("SIP UA-A"),
a SIP Proxy-1 server, a message dispatch facility-1 ("MDF-1") that
may be located at the SIP Proxy-1, an authorization server ("Auth
Srvr"), a user presence state facility ("UPSF"), and a notification
request facility ("NRF").
[0135] Referring to FIG. 11, as illustrated at 1102, the SIP UA-A
sends to the SIP Proxy-1 a REGISTER request message including an
Account ID-A associated with a user at a client device including
the SIP UA-A. The SIP Proxy-1 then sends an Authorization Admit
Request 1104 including the AccountID-A to the authorization server.
The authorization server, as illustrated at 1106, may access a user
profile in its authorization database to determine whether the user
is authorized to access the presence services. At step 1108, the
authorization server sends an Authorization Success message to the
SIP Proxy-1 and specifies the Account ID-A in the response message.
When the SIP Proxy-1 receives the authorization success message,
the SIP Proxy-1 replies to the SIP UA-A with a 200 OK message
1110.
[0136] Next, the SIP UA-A sends a notification message (NOTIFY)
1112 to the SIP Proxy-1. It should be understood that before
receiving any notification messages from the SIP UA-A, the SIP
Proxy-1 has subscribed to the SIP UA-A so that it can recognize and
process requests, such as NOTIFY, from the SIP UA-A. The
notification message may specify an event, such as a presence
service identifier (P_srvc_ID), a presence identifier of the user,
such as a Pres_ID_A, and a state of the user, such as Online. When
the SIP Proxy-1 receives the notification message, the SIP Proxy-1
sends to the authorization server an authorization update message
1114 (Auth_Update) including the Pres_ID_A, P_srvc_ID, and the
online state. When the authorization server receives the request
1114, the authorization server may rely the update request to the
UPSF, as illustrated at 1116. When the UPSF receives the request,
the UPSF processes the request, as illustrated at 1118. In one
embodiment illustrated at 1120, the UPSF may access a user presence
state database, change the presence state identifier of the user to
a pending state, and retrieve the Pres_ID_A's desired watch list.
It should be understood that the desired watch list may be provided
from the user.
[0137] Next, the UPSF sends a subscribe request message
(Subscribe_Rqst) 1122 to the NRF. The subscribe request message
includes the P_srvc_ID, Pres_ID-A, and the desired watch list. When
the NRF receives the subscribe request, the NRF processes the
request, as illustrated at 1124. Specifically, as illustrated at
1126, the NRF may access authorized subscriber lists of all
Pres_ID-A's desired watch list, and may add Pres_ID-A to current
subscribers list of each notifier for which the authorization is
successful. Further, the NRF may create an authorized watch list
for Pres_ID-A and may retrieve a Pres_ID-A's current subscriber
list.
[0138] The NRF may then generate and send to the UPSF a subscribe
response message ("Subscribe_Rsp) 1128. The subscribe response
message includes the P_srvc_ID, the Pres_ID-A, the authorized watch
list, and the Cur Subscribers list. At step 1130, the UPSF provides
an Update response message ("Update_Rsp") 1130 to the authorization
server. The Update_Rsp message 1130 includes parameters provided in
the Subscribe_Rsp message 1128. When the authorization server
receives the Update_Rsp 1130, the authorization server sends an
authorization success message 1132 ("Auth_Success") to the SIP
Proxy-1. The Auth_Success message 1132 includes Pres_ID_A,
P_srvc_ID, P_srvc_info, the online status, the authorization watch
list, and identifies current subscribers. Next, the SIP Proxy-1
provides to the MDF an update request ("Update_Rqst") 1134
including the Pres_ID_A, the P_srvc_ID, the P_srvc_init parameters.
At step 1136, the MDF may perform initialization actions that may
depend upon a to specific service.
[0139] Upon completion of the initialization process, the MDF
provides to the SIP Proxy-1 an update response message 1140
("Update_Rsp") including the Pres_ID_A, P_srvc_ID, and presence
service information ("P_srvc_info"). Responsively, the SIP Proxy-1
sends to the authorization message an authorization update message
1142 ("Auth_Update") including the P_srvc_ID, the Pres_ID_A, and an
initialization completion parameter ("init_complete"). When the
authorization server receives the message 1142, the authorization
server relies the message to the UPSF, as illustrated at 1144, and
the UPSF updates the state of the Pres_ID-A at step 1146. The UPSF
may access the user presence state database and change the state of
the Pres_ID-A to online, as illustrated at 1148. Next, the UPSF may
provide to the authorization server an update response message 1150
including the Pres_ID-A.
[0140] At step 1152, the authorization server sends to the SIP
Proxy-1 an authorization success message including the Pres_ID-A,
and the SIP Proxy-1 sends a 200 OK message to the SIP UA-A, as
illustrated at 1154. Next, the SIP Proxy-1 sends notification
messages ("NOTIFY") to the current subscribers of the Pres_ID-A and
their respective SIP Proxies.
User Request to Change a Presence State
[0141] The request to change a presence state is a generalization
of the request to go online. The request to go online illustrates
one case of specific actions, which are part of the request to
change the presence state. It should be understood that different
specific actions may be associated with different state change
requests, and the examples provided below should not be viewed as
limiting to any specific embodiment.
[0142] FIG. 12 is a flow chart illustrating a method 1200 for
changing a presence state of a user. At step 1202, the SIP UA
generates and sends to its SIP proxy server a notification request
message ("NOTIFY") including a request to change the state to a new
state. For example, the state change request may include a request
to change a state from online to offline. The notification request
message may define a Presence ID of a user, the presence service
requested, and may specify a new state. Additionally, the state
change request may include a desired watch list.
[0143] At step 1204, when the SIP proxy server receives the
request, the SIP proxy server relays the request for state change
to the centralized component of the presence services. In one
embodiment, the request may be relayed via the authorization server
using the 3Q protocol, for instance. At step 1206, the centralized
component of the presence service initializes the state change
request. The process of initialization the state change request may
include methods that have been described in reference to FIGS. 6,
7, and 8. However, it should be understood that different
embodiments are possible as well.
[0144] At step 1208, the centralized component of the presence
services generates and sends a response to the SIP proxy server. In
one embodiment, the response may be sent via the authorization
server using the 3Q protocol, for instance. Further, the response
may include the Presence ID, a current subscriber list for the
Presence ID, service related information, and an authorized watch
list. At step 1210, a distributed component of the presence
services initializes the requested services. Next, at step 1212,
the distributed presence function may determine if the response
includes a new authorized watch list. If the new authorized list is
included, the distributed component of the presence services
updates local authorized dispatchers lists associated with the
Presence ID, and the method 1200 continues at step 1216.
[0145] At step 1216, the SIP proxy server generates and sends to
the centralized components of the presence services an update
message including a parameter indicating that the service
initialization has been completed. The update message may also
include the Presence ID and service-related information.
[0146] At step 1218, the centralized component of the presence
services performs a process of completing the state change request,
the embodiment of which has been described in reference to FIG. 10.
At step 1220, the centralized component of the presence services
sends a response message to the SIP proxy server. The response may
be sent via the authorization server using the 3Q protocol and may
include the Presence ID. At step 1222, the SIP proxy server sends
to the SIP user agent a 200 OK message including the Presence ID
and the authorized watch list. Next, at step 1224, the SIP proxy
server may generate and send to each current subscriber a
notification message specifying the new state of the user.
Additionally, the SIP proxy server may send the notification
message to SIP proxy servers associated with the current
subscribers. The notification messages include the Subscriber ID,
the new state, and service related information. At step 1226, the
SIP user agent may perform any service-specific setup and update
processes, and the method 1200 terminates.
[0147] FIG. 13 is a message flow 1300 illustrating a method for
requesting a state change for a user at a client device. The
message flow 1300 will be described in reference to the SIP UA-A,
the SIP Proxy-1, the MDF, the authorization server, the UPSF, and
the NRF.
[0148] The SIP UA-A sends a notification message (NOTIFY) 1302 to
the SIP Proxy-1. The notification message may specify an event,
such as a presence service identifier (P_srvc_ID), a presence
identifier of the user, such as a Pres_ID_A, and a new state. When
the SIP Proxy-1 receives the notification message, the SIP Proxy-1
sends to the authorization server an authorization update message
1304 (Auth_Update) including the Pres_ID_A, P_srvc_ID, and the new
state requested from the SIP UA-A. When the authorization server
receives the request 1304, the authorization server may rely the
update request to the UPSF, as illustrated at 1306. When the UPSF
receives the request, the UPSF processes the request, as
illustrated at 1308. In one embodiment illustrated at 1310, the
UPSF may access a user presence state database, change the presence
state identifier of the user to a pending state, and retrieve the
Pres_ID_A's desired watch list.
[0149] Next, the UPSF sends a subscribe request message
(Subscribe_Rqst) 1312 to the NRF. The subscribe request message
includes the P_srvc_ID, Pres_ID-A, and the desired watch list. When
the NRF receives the subscribe request, the NRF processes the
request, as illustrated at 1314. Specifically, as illustrated at
1316, the NRF may access authorized subscriber lists of all
notifiers in the Pres_ID-A's desired watch list, and may add
Pres_ID-A to current subscribers list of each notifier for which
the authorization is successful. Further, the NRF may create an
authorized watch list for Pres_ID-A and may retrieve a Pres_ID-A's
current subscriber list.
[0150] The NRF may then generate and send to the UPSF a subscribe
response message ("Subscribe_Rsp) 1318. The subscribe response
message includes P_srvc_ID, the Pres_ID-A, the authorized watch
list, and the Cur Subscribers list. At step 1320, the UPSF provides
an Update response message ("Update_Rsp") to the authorization
server. The Update_Rsp message 1320 includes parameters provided in
the Subscribe_Rsp message 1318. When the authorization server
receives the Update_Rsp 1320, the authorization server sends an
authorization success message 1322 ("Auth_Success") to the SIP
Proxy-1. The Auth_Success message 1322 includes Pres_ID_A,
P_srvc_ID, P_srvc_info, the online status, the authorization watch
list, and identifies current subscribers. Next, the SIP Proxy-1
provides to the MDF an update request ("Update_Rqst") 1324
including the Pres_ID_A, the P_srvc_ID, the P_srvc_init parameters.
At step 1326, the MDF may perform initialization actions that may
depend upon the specific service, and the specific actions may
depend upon a specific service, as illustrated at 1328.
[0151] Upon completion of the initialization process, the MDF
provides to the SIP Proxy-1 an update response message 1330
("Update_Rsp") including the Pres_ID_A, P_srvc_ID, and presence
service information ("P_srvc_info"). Responsively, the SIP Proxy-1
sends to the authorization message an authorization update message
1332 ("Auth_Update") including the P_srvc_ID, the Pres_ID_A, and an
initialization completion parameter ("init_complete"). When the
authorization server receives the message 1332, the authorization
server relies the message to the UPSF, as illustrated at 1334, and
the UPSF updates the state of the Pres_ID-A at step 1336. The UPSF
may access the user presence state database and change the state of
the Pres_ID-A to the new state, as illustrated at 1338. Next, the
UPSF may provide to the authorization server an update response
message 1340 including the Pres_ID-A.
[0152] At step 1342, the authorization server sends to the SIP
Proxy-1 an authorization success message including the Pres_ID-A,
and the SIP Proxy-1 sends a 200 OK message to the SIP UA-A, as
illustrated at 1344. Next, the SIP Proxy-1 sends notification
messages ("NOTIFY") to the current subscribers of the Pres_ID-A and
their respective SIP Proxies, as illustrated at 1346. When one of
the current subscriber's SIP proxies such as a SIP Proxy 2
illustrated in FIG. 13 receives the notification message from the
SIP Proxy 1, the SIP Proxy 2 sends an update request message 1348
to its MDF, such as an MDF 2 illustrated in FIG. 13. The update
request message, among other parameters, includes P_srv_ID,
Pres_ID-A, and an indication that the update request is from the
Pres_ID-B. At step 1350, the MDF-2 processes the request, and,
specifically, as illustrated at 1352, accesses the Pres_ID-A's
authorized dispatcher's list and updates the list as required. At
step 1354, the MDF 2 sends an update response to the SIP Proxy 2
including the Pres_srvc_ID, the Pres_ID-A, and the Pres_ID-B. The
message flow 1300 may terminate with the SIP UA-B sending a 200 OK
message to the SIP Proxy 2 and to the SIP Proxy 1.
[0153] FIG. 14 is a flow chart illustrating a method 1400 for
subscribing to a presence entity as a watcher.
[0154] At step 1402, a SIP UA generates and sends to a SIP proxy
server a subscription request including a requester's Presence ID,
a desired notifier's Presence ID (or notifiers' IDs), and a
requested presence service. At step 1404, the SIP proxy server
relays the request to a centralized component of presence services.
In one embodiment, the SIP proxy server may relay the request via
an authorization server using the 3Q protocol, for instance. The
relayed request includes the data received in the original request.
At step 1406, the centralized component of the presence services
uses the received desired notifier's Presence IDs to generate a
desired watch list. It should be understood the SIP UA or the SIP
proxy server may also create a desired watch list using the desired
notifiers' information provided by the user.
[0155] At step 1408, the centralized component of the presence
services validates the subscription request, the method of which
has been described in reference to FIG. 7. At step 1410, the
centralized component of the presence services updates current
subscribers lists of willing notifiers, the method of which has
been described in reference to FIG. 8. At step 1412, the
centralized component of the presence services generates and sends
to the SIP proxy server a response message including the Presence
ID of the requester, an authorized watch list, and service-related
information.
[0156] At step 1414, a distributed component of the presence
services updates authorized local dispatchers lists, the method of
which has been described in reference to FIG. 9. At step 1416, the
SIP proxy server sends to the SIP UA a 200 OK message including the
Presence ID of the requester, and the authorized watch list. At
step 1418, the SIP proxy server sends a notification message
(NOTIFY) to the SIP UA, and the SIP UA responds with a 200 OK
message. At step 1420, the SIP UA may perform service-specific
setup/update actions, and the method 1400 terminates.
[0157] FIG. 15 is a message flow 1500 illustrating a method for
subscribing to a presence entity as a watcher. The message flow
1500 will be described in reference to the SIP UA-A, the SIP
Proxy-1, MDF-1, the authorization server ("Auth srvr"), the UPSF,
and the NRF.
[0158] The SIP UA-A sends a subscription request message 1502
("SUBSCRIBE") to the SIP Proxy-1. The subscription request message
1502 identifies the requested service, and a desired notifier's ID
(Pres_ID-B). The SIP Proxy-1 sends an authorization permission
request message 1504 ("Auth_Permit") to the authorization server.
The authorization message 1504 includes the presence identifier of
the requester (Pres_ID-A), the presence identifier of the desired
notifier (Pres_ID-B), and the presence service identifier
("P_srvc_ID").
[0159] When the authorization server receives the request, the
authorization server sends a subscription request message 1506
("Subscribe_Rqst") to the NRF. The subscription request message
1506 includes the presence service ID, the Pres_ID-A, and the
Pres_ID-B. At step 1508, the NRF processes the request.
Specifically, as illustrated in 1510, the NRF may access the
Pres_ID-B's authorized subscribers list to determine if the
Pres_ID-A is specified in that list. If so, the NRF adds the
Pres_ID-A to the Pres_ID-B's current subscribers list.
[0160] At step 1512, the NRF generates and communicates to the
authorization server a subscription response message 1512
("Subscribe_Rsp") including the P_srvc_ID, the Pres_ID-A, the
Pres_ID-B, and a status of the request. In this example, the status
may specify that the Pres_ID-A has been added to the current
subscriber's list of the Pres_ID-B. The authorization server then
sends an authorization response message 1514 ("Auth_Success") to
the SIP Proxy-1. When the SIP Proxy 1 receives the successful
authorization response message, the SIP Proxy-1 sends to the MDF-1
an update request message 1516 ("Update_Rqst") including the
Pres_ID-A, the Pres_ID-B, and a dispatch list update request. When
the MDF-1 receives the request, the MDF processes the request at
step 1518. Specifically, as illustrated at 1520, the MDF-1 may
first determine if an authorized dispatchers list exists for the
Pres_ID-B, and, if so, the MDF-1 adds the Pres_ID-A to the
Pres_ID-B's authorized dispatchers list. The MDF-1 then sends to
the SIP Proxy-1 an update response message 1522 ("Update_Rsp")
including the Pres_ID-A, the Pres_ID-B, and an update status. In
this example, the update status may include a successful update
parameter. Next, the SIP Proxy-1 sends a 200 OK message 1524 to the
SIP UA-A. Additionally, the SIP Proxy-1 sends a notification
message 1526 ("NOTIFY") to the SIP UA-A, and the SIP UA-A replies
with a 200 OK message 1528.
User Request to Subscribe as a Solicitor
[0161] According to an exemplary embodiment, a user may request to
subscribe as a solicitor in order to be immediately notified by the
presence system of the current state of a presence entity specified
by the user requesting that type of subscription. It should be
understood that a watcher request may be part of a solicitor
request; however, such a request will be authorized by a desired
notifier. As described above, the authorization may be either
maintained in the desired notifier's authorized subscribers list or
obtained dynamically by querying a desired notifier at the time
when the subscription request is made.
[0162] FIG. 16 is a flow chart illustrating a method 1600 for
subscribing to a presence entity as a solicitor.
[0163] At step 1602, a SIP UA generates and sends to a SIP Proxy
server a subscription request including the requester's Presence
ID, a desired notifier's Presence ID (or multiple notifiers'
Presence IDs), and a request type indicating a solicitation
request. Additionally, the subscription request may include a watch
request. At step 1604, the SIP proxy server relays the request to
the centralized component of the presence services. According to an
exemplary embodiment, the request may be relayed via an
authorization server using the 3Q protocol, for example, and the
relayed request includes all parameters specified in the original
subscription request.
[0164] At step 1606, when the centralized component of the presence
services receives the request, the centralized component uses
desired notifiers as a desired watch list. It should be understood
that formatting of desired notifiers as a desired watch list may be
also done on the SIP UA or the SIP Proxy. Next, at step 1608, the
centralized component of the presence services validates
subscription requests, the method of which has been described in
reference to FIG. 7. At step 1610, the centralized component
determines if the received request includes a watch request. If the
request includes the watch request, at step 1612, the centralized
component updates current subscribers lists of willing notifiers,
the method of which has been described in reference to FIG. 8.
[0165] At step 1614, the centralized component of the presence
services retrieves presence states from user presence data
resources associated with the desired notifiers, the method of
which will be described in greater detail below in reference to a
flow chart in FIG. 17. At step 1616, the centralized component of
the presence services sends a response message to the SIP proxy
server. In one embodiment, the response may be sent via the
authorization server using the 3Q protocol, for instance. Further,
the response may include the Presence ID, the requested presence
states, an authorized watch list, and service-related
information.
[0166] At step 1618, a distributed component of the presence
services updates local authorized dispatchers lists, the method of
which has been described in reference to FIG. 9. At step 1620, the
SIP proxy server sends a 200 OK message to the SIP UA, and the 200
OK message includes the Presence ID of the requester, the requested
presence states, and the authorized watch list (if requested). At
step 1622, the SIP proxy server sends a notification message
("NOTIFY") to the SIP UA, and the SIP UA responds with a 200 OK
message. At step 1624, the SIP UA may perform service-specific
setup and update actions, and the method 1600 terminates.
[0167] FIG. 17 is a flow chart illustrating a method 1700 for
retrieving presence states from user presence state data resources
by a centralized component of the presence services. Specifically,
the method 1700 illustrates a detailed description for the step
1614 in FIG. 16.
[0168] At step 1702, the centralized component of the presence
services receives a request to retrieve presence states form user
presence state data resources, and the request includes an
authorized watch list specified by a requesting user. At step 1704,
the centralized component retrieves presence state of each willing
notifier in the authorized watch list. Further, the centralized
component may repeat update steps for each willing notifier in the
authorized watch list. At step 1706, the centralized component
returns a completion status, if such a status is required, and the
method 1700 terminates.
[0169] FIG. 18 is a message flow 1800 illustrating a method for
subscribing to a presence service as a solicitor. The message flow
1800 will be described in reference to the following entities: the
SIP UA-A, the SIP Proxy-1, the MDF-1, the authorization server
("Auth Srvr"), the UPSF, and the NRF. However, it should be
understood that the exemplary message flow is not limited to these
entities, and it could also be used in reference to different or
equivalent entities.
[0170] Referring to the message flow 1800, the SIP UA-A sends a
subscription request message 1802 ("SUBSCRIBE") to the SIP Proxy-1,
and the subscription request message includes a presence service
identifier ("P_srvc_ID"), a request type set to pull presence
state, the requester's presence identifier ("Pres_ID-A"), and an
identifier of one or more desired notifiers' identifiers
("Pres_ID-B", in this example). When the SIP Proxy-1 receives the
request, the SIP Proxy-1 generates and sends to the authorization
server an authorization permission request message 1804
("Auth_Permit") including the information received in the
subscription request 1802.
[0171] Next, the authorization server relies the request to the NRF
in a subscription request message 1806 ("Subscribe_Rqst"). When the
NRF receives the request, the NRF processes the request, as
illustrated in 1808. Specifically, as illustrated at 1810, the NRF
may first access Pres_ID-B's authorized subscribers list to
determine if the Pres_ID-A is specified in the list. If the
Pres_ID-A is specified in the list, the NRF may add the Pres_ID-A
to the Pres_ID-B's current subscribers list. Next, the NRF sends an
update request message 1812 ("Update_Rqst") to the UPSF. The update
request message 1812 includes the Pres_ID-B and the request type,
which in this example is a pull request type. When the UPSF
receives the request, the UPSF processes the request, as
illustrated at 1814. Specifically, the UPSF accesses user presence
state data resources and retrieves the state of the Pres_ID-B, as
illustrated at 1816. Next, the UPSF generates and sends to the NRF
an update response message 1818 ("Update_Rsp") including the
Pres_ID-B and the current state of the Pres_ID-B.
[0172] Responsive to receiving the update response message 1818,
the NRF sends to the authorization server a subscribe response
message 1820 ("Subscribe_Rsp") including the P_srvc_ID, Pres_ID-A,
Pres_ID-B, and the current state of the PresID-B. The authorization
server then sends an authorization success message 1822
("Auth_Success") to the SIP Proxy-1. The authorization success
message 1822, among other parameters, includes the Pres_ID-A, the
Pres_ID-B, Psrvc_ID, and the current state information for the
Pres_ID-B. When the SIP Proxy-1 receives the message 1822, the SIP
Proxy-1 sends an update request message 1824 to the MDF-1. The
update request message 1824 includes the Pres_ID-A, the Pres_ID-B,
P_srvc_ID, and an update dispatch list request. The MDF-1 may then
process the request as illustrated at 1826. To do that, the MDF-1
may access the Pres_ID-B's authorized dispatchers list and enter
the Pres_ID-A as an authorized dispatcher. Next, the MDF-1 sends an
update response message 1830 ("Update_Rsp") to the SIP Proxy-1. The
update response message 1830 includes the Pres_ID-A, the Pres_ID-B,
the P_srvc_ID, and the status of the update.
[0173] When the SIP Proxy-1 receives the update response 1830, the
SIP Proxy-1 sends a 200 OK message 1832 to the SIP UA-A.
Additionally, the SIP Proxy-1 sends a notification message 1834
("NOTIFY") including the Pres_ID-B and its current state
information. The SIP UA-A may respond with a 200 OK message 1836
upon receipt of the notification message 1834, and the message flow
1800 terminates.
User Request to Dispatch a Message
[0174] According to an exemplary embodiment, a user request to
dispatch a message is made through a user's SIP Proxy, and is
carried out by a distributed component of the presence services
associated with that SIP Proxy.
[0175] FIG. 19 is a flow chart illustrating a method 1900 for
dispatching a message. At step 1902, a SIP UA generates and sends a
notification message to a SIP proxy server. According to an
exemplary embodiment, the notification message includes a
requester's Presence ID, an intended recipient's Presence ID (or
Presence IDs), a presence service type, and an event type, such as
dispatch a message. Additionally, the notification message may
include a start message indicator.
[0176] When the SIP Proxy server receives the request, at step
1904, the SIP Proxy server may identify the message as a message
dispatch request and may deliver the request to its local
distributed component of the presence services. Specifically, the
distributed component may be an MDF located on the SIP Proxy
server. At step 1906, the distributed component of the presence
services validates the dispatch request, the method of which will
be described in greater detail in reference to a flow chart in FIG.
20.
[0177] At step 1908, the distributed component determines if there
are any valid requests. If there are no valid requests, the
distributed component denies the request, and the method continues
at step 1916. If there is at least one valid request, at step 1910,
the distributed component determines if a start message indicator
is included in the request. For example, the start message
indicator may be used to indicate that a media path should be
established. In such an embodiment, a stop message indicator may be
used to disable the same media path. However, different embodiments
are possible as well. If a start message indicator is not included
in the request, at step 1912, the SIP proxy server sends a user's
message to the intended recipients. When the message is sent, at
step 1914, the SIP proxy server also sends a 200 OK message to the
SIP UA. At step 1916, the SIP UA may perform service-specific
message complete actions that terminate the message dispatch
method. For example, this step may involve updating the user
interface display.
[0178] Referring back to step 1910, if the request includes a start
message indicator, at step 1918, the SIP proxy server initializes a
message dispatch function. According to an exemplary embodiment,
the SIP proxy server may carry out any actions that are required to
prepare for sending of a separate message stream. For example, in
the case of IP Intercom, the SIP proxy may instruct the conference
server to bridge the send and receive ports for the voice message
stream (media stream) that has been established during the
registration of the user.
[0179] At step 1920, the SIP Proxy server sends a 200 OK message to
the SIP UA. The 200 OK message includes the Presence ID of the
requester, and an indicator that the message path has been enabled.
At step 1922, the SIP UA carries out service-specific send-message
actions. This subtask may be invoked to activate and carry out the
sending of a separate message stream by the SIP UA in the case
where the message dispatch involves the start and stop phases. The
service-specific send-message actions may depend upon the type of
messages being sent. This subtask may be executed to send the user
data that form a separate message stream. For example, this subtask
might be used to activate the media stream from the client device
and cause data to be transmitted to a predetermined network
entity.
[0180] At step 1924, the SIP UA sends a notification message
("NOTIFY") to the SIP proxy server. According to an exemplary
embodiment, the notification message includes the requester's
Presence ID, and an intended recipient's Presence ID (or Presence
IDs associated with more than one recipient). Additionally, the
notification message includes an event type indicator, i.e., a
dispatch indicator, in this example, and a stop message indicator.
At step 1926, the distributed entity of the presence services
validates the dispatch request, the method of which will be
described in greater detail in reference to FIG. 20.
[0181] At step 1928, the distributed entity of the presence
services determines if there are any valid requests. If there are
no valid requests, the method continues at step 1916. If there are
any valid requests, at step 1930, the SIP Proxy server terminates
sending of a separate message stream. Specific actions of
terminating the message stream may depend upon the type of messages
being sent. For example, the step of terminating the message stream
may include deactivation of a media stream that has been
established from the client device. In the case of the IP intercom
described in the U.S. patent application Ser. No. 10/021,171, this
step may deactivate the media stream from the client device and
cause the conference server's ports between the sender and
receiver(s) to be unbridged. It should be understood that different
embodiments are possible as well. At step 1932, the SIP Proxy
server generates and sends to the SIP UA a 200 OK message. The 200
OK message may include the Presence ID of the requester, and a
message path disabled indicator, and the method continues at step
1916.
[0182] FIG. 20 is a flow chart illustrating a method 2000 for
validating dispatch requests. Specifically, the method 2000
illustrates a detailed flow chart for the step 1926 in FIG. 19. At
step 2002, the distributed element of the presence services
receives a request to validate a dispatch request to an intended
recipient. According to an exemplary embodiment, the request may
include the Presence ID of the sender, the Presence ID(s) of
intended recipient(s), and the presence service type.
[0183] At step 2004, the distributed element of the presence
services validates each dispatch request in the list of would-be
recipients' Presence IDs. The validation steps are repeated for
each intended recipient. At step 2006, the distributed element of
the presence services determines if an authorized dispatcher list
exist for each intended recipient. If an authorized dispatcher list
exists, at step 2008, the distributed element retrieves an
authorized dispatcher list of each intended recipient. At step
2010, the distributed element determines if the user's Presence ID
is in the retrieved list, and if any privileges or restrictions are
specified for the Presence ID. If so, at step 2012, the distributed
element retrieves the intended recipient's contact information,
and, at step 2014, validates the request for this intended
recipient. For example, the distributed element adds this intended
recipient's Presence ID and contact information to the validated
list for return, and the method continues at step 2018.
[0184] Referring back to step 2006, if the authorized dispatchers
list does not exist for a predetermined recipient, at step 2016,
the distributed element does not validate the request for that
recipient. If any authorized dispatchers lists exist and the user's
Presence ID is in one or more of those lists, and further, if the
distributed element validated each dispatcher request, at step
2018, the validation process is completed. Further, at step 2020,
the distributed element returns the validated dispatch list to the
SIP Proxy server associated with the user (requester), and the
method 2000 terminates.
[0185] FIG. 21 is a message flow 2100 illustrating a method for
requesting a message dispatch. The message flow 2100 will be
described in reference to the following entities: the SIP UA-A, the
SIP Proxy-1, the MDF-1, the authorization server ("Auth Srvr"), the
UPSF, and the NRF. However, it should be understood that different
entities could also be used.
[0186] The SIP UA-A sends a notification message 2102 ("NOTIFY") to
its SIP Proxy-1. The notification message 2102 specifies a request
type, i.e., a dispatch request, the Presence ID of the requester
(the Presence ID-A), and the Presence ID of the intended recipient
(Presence ID-B). Further, the notification message may specify a
start operation request. The SIP Proxy-1 generates and provides to
its MDF-1 a dispatch request message 2104 including the data
specified in the notification message 2102. When the MDF-1 receives
the dispatch request, the MDF-1 processes the request, as
illustrated at step 2106. Specifically, as illustrated at 2108, the
MDF-1 may access the Pres_ID-B's authorized dispatchers list and
determines if Pres_ID-A is in the Pres_ID-B's authorized
dispatchers list.
[0187] The MDF-1 then sends a dispatch response message 2110
("Dispatch_Rsp") including the Pres_ID-A, the Pres_ID-B, and a
status of the request. For example, the status may indicate that
the Pres_ID-A is authorized to dispatch a message to the Pres_ID-B.
When the SIP Proxy-1 receives the dispatch response message 2110,
and the status of the request indicates that the Pres_ID-A is
authorized to dispatch a message to the Pres_ID-B, at step 2112,
the SIP Proxy-1 dispatches a message from the SIP UA-A. As
illustrated in FIG. 21, specific actions to dispatch a message may
depend on a specific service and a message type, and, thus, are not
illustrated in FIG. 21. Upon a successful dispatch of the message,
the SIP Proxy-1 sends a 200 OK message 2114 to the SIP UA-A.
[0188] FIG. 21 further illustrates a message flow that may be
optionally performed for specific message services that use start
and stop operations. The illustrated message flow is intended to
invoke the stop operation. In one embodiment, a stop indicator may
be used to disable a message path that has been established based
on a start message indicator specified in the notification message
2102. In such an embodiment, the SIP UA-A sends to the SIP Proxy-1
a notification message 2118 ("NOTIFY") including the dispatch
service type, the Pres_ID-A (sender), the Pres_ID-B (recipient),
and the stop message indicator. According to an exemplary
embodiment, the SIP Proxy-1 sends a dispatch request message 2120
("Dispatch_Rqst") to the MDF-1, and the dispatch request message
2120 includes the data specified in the message 2118. When the
MDF-1 receives the request 2120, the MDF-1 processes the request,
as illustrated at 2122. Specifically, the MDF-1 determines if the
Pres_ID-A is in the authorized dispatcher list of the Pres_ID-B. If
the Pres_ID-A is in the authorized dispatcher list of the
Pres_ID-B, the MDF-1 sends to the SIP Proxy-1 a dispatch response
message 2126 ("Dispatch_Rsp") including the Pres_ID-A, the
Pres_ID-B, and the stop indicator specifying that the Pres_ID-A is
authorized to disable the message path, for example. At step 2128,
the SIP Proxy-1 may perform stop dispatch operations that may
depend upon a specific service and a message type. Once the stop
operations conclude, the SIP Proxy-1 sends a 200 OK message to the
SIP UA-A, and the message flow 2100 terminates.
User Request to Cancel Subscription
[0189] FIG. 22 is a flow chart illustrating a method 2200 for
canceling a subscription according to one exemplary embodiment. At
step 2202, the SIP UA sends to the SIP Proxy server a subscription
request message including a subscription cancellation indicator.
The subscription request message further includes the requester's
Presence ID, Presence ID(s) of one or more notifiers, and an
identifier of the requested presence service. At step 2204, the SIP
Proxy server relays the request to the centralized component of the
presence services. According to an exemplary embodiment, the
request may be relayed via the authorization server using the 3Q
protocol, for instance.
[0190] At step 2206, the centralized component uses the specified
notifiers to generate a cancellation list. It should be understood
that the method of generating the cancellation list is not limited
to being generated at the centralized component, and it could also
be generated at the SIP UA, or the SIP Proxy, for example. At step
2208, the centralized component updates the current list of willing
notifiers, the embodiment of which has been described in reference
to FIG. 8, and the parts describing the subscription cancellation
are pertinent here. At step 2210, the centralized element of the
presence services responds to the SIP proxy server. According to an
exemplary embodiment, the response may be sent via the
authorization server, and includes the Presence ID, and the return
status.
[0191] At step 2212, the distributed element of the presence
services updates local authorized dispatchers lists, the method of
which has been described in reference to FIG. 9. At step 2214, the
SIP proxy server sends a 200 OK message to the SIP UA, and the 200
OK message includes the Presence ID of the requester. At step 2216,
the SIP Proxy server sends to the SIP UA a notification message
("NOTIFY"), and the SIP UA responds with a 200 OK message. At step
2218, the SIP UA may perform service-specific setup/update actions.
For example, the SIP UA may display to the user that the
subscription has been cancelled.
[0192] FIG. 23 is a message flow 2300 illustrating a method for
subscription cancellation. The message flow 2300 will be described
in reference to the following entities: the SIP UA-A, the SIP
Proxy-1, the MDF-1, the authorization server ("Auth Srvr"), the
UPSF, and the NRF. However, it should be understood that different
entities could also be used.
[0193] The SIP UA-A sends a subscription request message 2302
("SUBSCRIBE") to the SIP Proxy-1. The subscription request message
2302 includes P_srvc_ID, a subscription cancellation request
identified with "expire=0," the Pres_ID-A of the requester, and the
request to cancel the subscription to the Pres_ID-B.
[0194] The SIP Proxy-1 then sends an authorization permission
request message 2304 ("Auth_Penn") including a request to cancel
the subscription of the Pres_ID-A to the Pres_ID-B. The
authorization server then sends to the NRF an unsubscribe request
message 2306 ("UnSubscribe_Rqst") including the P_srvc_ID, the
Pres_ID-A, and the Pres_ID-B. At step 2308, the NRF processes the
request. Specifically, at step 2310, the NRF removes the Pres_ID-A
from the Pres_ID-B's current subscribers list. Responsively, the
NRF sends an unsubscribe response message 2312 ("UnSubscribe_Rsp")
to the authorization server. The unsubscribe response message 2312
includes the P_srvc_ID, the Pres_ID-A, and the Pres_ID-B.
[0195] The authorization server then sends an authorization success
message 2314 ("Auth_Success") to the SIP Proxy-1. The authorization
success message 2314 includes the Pres_ID-A, the Pres_ID-B, the
P_srvc_ID, and the indicator that the subscription has been
cancelled (indicated in FIG. 23 using an "expired" parameter). When
the SIP Proxy-1 receives the message 2314, the SIP Proxy-1 sends an
update request message 2316 ("Update_Rqst") to its MDF-1. The
update request message 2316 includes the Pres_ID-A, the Pres_ID-B,
the P_srvc_ID, and a status indicating the subscription
cancellation. When the MDF-1 receives the message 2316, at step
2318, the MDF-1 processes the request. Specifically, as illustrated
at 2320, the MDF-1 accesses the Pres_ID-B's authorized dispatchers
list and removes the Pres_ID-A from the Pres_ID-B's authorized
dispatchers list. If the list of the Pres_ID-B's becomes empty, the
list may be deleted. The MDF-1 then sends an update response
message 2322 ("Update_Rsp") to the SIP Proxy-1, and the update
response 2322 includes the Pres_ID-A, the Pres_ID-B, the P_srvc_ID,
and a status indicating that the Pres_ID-A has been removed from
the Pres_ID-B's list. The SIP Proxy-1 may then send a 200 OK
message 2324 to the SIP UA-A indicating the completion of the
cancellation process.
[0196] It should be understood that the programs, processes,
methods and systems described herein are not related or limited to
any particular type of computer or network system (hardware or
software), unless indicated otherwise. Various types of general
purpose or specialized computer systems supporting the IP
networking may be used with or perform operations in accordance
with the teachings described herein.
[0197] In view of the wide variety of embodiments to which the
principles of the present invention can be applied, it should be
understood that the illustrated embodiments are examples only, and
should not be taken as limiting the scope of the present invention.
For example, the steps of the flow diagrams may be taken in
sequences other than those described, more or fewer steps may be
used, and more or fewer elements may be used in the block diagrams.
While various elements of the preferred embodiments have been
described as being implemented in software, in other embodiments in
hardware or firmware implementations may alternatively be used, and
vice-versa.
[0198] Further, it will be apparent to those of ordinary skill in
the art that methods involved in the system for instant voice
messaging may be embodied in a computer program product that
includes one or more computer readable media. For example, a
computer readable medium can include a readable memory device, such
as a hard drive device, CD-ROM, a DVD-ROM, or a computer diskette,
having computer readable program code segments stored thereon. The
computer readable medium can also include a communications or
transmission medium, such as, a bus or a communication link, either
optical, wired or wireless having program code segments carried
thereon as digital or analog data signals.
[0199] The claims should not be read as limited to the described
order or elements unless stated to that effect. Therefore, all
embodiments that come within the scope and spirit of the following
claims and equivalents thereto are claimed as the invention.
* * * * *