User Application Data: a Panorama

I tend to think that IMS and all-IP will make the telecommunications industry move from an era where the typical technical challenge was to design a specific solution for every problem to a new one where the main difficulty will be to select one solution among many candidates.

An illustration of this is user profile management and storage in the future application layer.

In this post I will try to make a panorama of standards and industry trends that may impact this topic in the years to come. In another one, I will express some personal opinions about the way to go.

User Profile Data in the HSS (Diameter, unspecified data format)

The Home Subscriber Server (called UPSF for fixed networks) is the database to store all the user data required by the IMS core network to fulfill its duties.

Additionally, the IMS service architecture has an interface between the HSS and the SIP Application Server called Sh.

This interface is based on Diameter and can be used by the application server for two purposes:

- Accessing user data normally stored in the HSS (or in the HLR), such as the user registration status, the S-CSCF that serves the user, or the service profile associated to the user.

- Storing application data in the HSS. This data is transparent to the HSS, i.e. it does not understand its format and semantic.

Sh supports a Diameter-based notification mechanism, permitting to alert the application server when data has been modified.

Most suppliers support the data repository feature of the HSS. It should be noted that the HSS is a mission critical database, which tends to constitute a major portion of the cost of an IMS core network. In this context, the application data repository feature of the HSS and associated questions (e.g. how much data will be stored in it? How much traffic will it generate?) raises questions about the required characteristics for the HSS and its eventual cost for an operator.

User Profile Data in SIP Application Servers (SIP/XCAP, XML)

In the IMS service architecture, there is a reference point called Ut between IMS clients and Application Servers that is used for service customization. This interface is based on XCAP, a simple HTTP based protocol specified in the IETF, which permits to access and manage data defined as XML documents.

The IMS service architecture therefore implies that a SIP application server can own the user data corresponding to the services it supports. This is a quite straightforward and optimized approach to co-locate user service data with the services that make use of them.

In the Automatic Service Discovery & Configuration example, I showed how a SIP event package (i.e. SUBSCRIBE, NOTIFY, PULBLISH) can be used by an IMS client to easily retrieve the XCAP location of user data associated to the user (SUBSCRIBE is addressed to one of the user's Public Identities) or to a specific service associated to the user (SUBSCRIBE is addressed to Public Service Identity). The XCAP URI can then be provided to the client in a NOTIFY. The event package also permits the client to monitor changes to the data (as in the IETF, a SIP event package is used to monitor changes in data manipulated using XCAP). These mechanisms can also be used within the network for an application server to retrieve user data in another application server.

XCAP Data Management Servers (XCAP, XML)

Based on XCAP, the Open Mobile Alliance (OMA) defined an architecture for user data management which consists of XCAP Data Management Servers (XDMS). You can see figures in this page from Tech-invite.

OMA decided to define a Shared XDMS storing common data between different services/enablers, as well as a specific XDMS for each of them (e.g. push to talk, presence, resource lists). Each of these XDMS is logically separated from the SIP application server supporting the corresponding service/enabler.

In practice, this ambiguous architecture is likely to lead to two implementation options:

1) The supplier decides to implement a network database called XDMS to store all XCAP data, i.e. OMA Shared XDMS and all the service/enabler -specific XDMS. This database is accessed through the XCAP protocol. A priori, it does not support any SIP event package, which may lead to synchronization problems with clients.

2) The supplier decides to combine each service/enabler specific XDMS in the SIP application server supporting the corresponding application. This approach is more in line with the 3GPP service architecture for which Ut (XCAP) and ISC (SIP) terminate to the same entity. It also corresponds to the user-profile-data-in-SIP-AS option above. It permits to support the SIP event package for monitoring of changes in the user data. The supplier may also decide to implement the Shared XDMS as a SIP AS.

Presence (SIP/XCAP, XML)

It might seem strange to list presence, a specific IMS service/enabler, as a potential data repository.

Actually, presence has considerably evolved since the early days when it only supported instant messaging and the IETF suggested to implement it as part of the basic SIP registrar function.

Through multiple extensions to its baseline XML schema, presence can now be considered as an extensive set of static and dynamic information about the user, its devices and its applications. In this context, presence can be seen as an essential repository of user data, that can be used as an enabler by many IMS applications.

In a network in which presence is a basic enabler associated to every user, some data currently considered as user application data, that the user manages service per service, may simply be part of the user's presence. To take a trivial example, presence may eventually make the explicit definition of forwarded-to-numbers for call management services totally irrelevant.

Presence is a specific example of the user-data-in-SIP-AS approach described above.

Generic User Profile (SOAP, XML)

GUP is a 3GPP standard, which is independent from IMS but that can optimally be used with it.

To make it short, GUP permits to define a virtual centralized user database, by enabling an homogeneous and centralized access to distributed user profile components, stored in network databases (e.g. HLR, HSS) and application servers.

The GUP location server is called GUP Server. A client application asks to access user data by providing the identity of the user (e.g. an IMS public identity) and the name of user profile components it wants to access. The GUP server either provides in return the address of the GUP data repository (e.g. an application server) or accesses the data on behalf of the application).

GUP interfaces are based on SOAP and the user data is defined according to a hierarchical XML schema (GUP does not specify the data itself). As GUP aims at supporting Liberty Alliance (set of web services towards 3rd party service providers) within the 3GPP network, GUP interfaces totally align with the Liberty Alliance Project specifications.

The GUP architecture can be compared to the user-data-in-SIP-AS approach in which:

- SOAP replaces SIP/XCAP to access and monitor changes in user data

- The GUP server and its location data plays the role the S-CSCF making use of service profiles endorses with SIP

More especially, the two approaches are able to dispatch a request based on the identity of a target user.

Common Profile Store (LDAP)

Every supplier or operator has its own name for this concept, but CPS is the term under which 3GPP has been addressing it.

CPS originates from a recent telecom industry trend which aims at changing the monolithic nature of network databases (e.g. HLR, HSS, AAA, application servers) into a multi-tiered IT architecture, in which the business logic of the database (e.g. Diameter features of HSS, MAP features from HLR) is physically separated from data storage. An LDAP server supporting telco-grade requirements (e.g. availability, capacity, performance) is shared between stateless business logic frontends implementing a variety of network entities.

CPS permits to optimize and rationalize the architecture of network databases. It also permits to reduce vendor locking achieved through monolithic network databases.

While it does not impose it, CPS also favors a more coherent modeling of user data across the various network databases and application servers, which permits to decrease operating costs and to foster new synergies.

In the context of IMS, CPS would permit to remove the need for a direct interface between the HSS and the HLR (required for Sh) by permitting user data sharing through access to the common backend.

Integration with open service platforms (e.g. J2EE, JAIN SLEE) would permit to use CPS for all applications implemented on these platforms.

So many possibilities... In the next post, I will provide personal opinions on them.

Christophe

IMS Service Features

The Automatic Service Discovery and Configuration example permits to highlight some of the key features of an IMS-based application layer.

Many of these features directly relate to what I consider to be the fundamental trait of the IMS service architecture: its user orientation.

The power of SIP

The example permitted to exhibit two important features of the SIP protocol, that I have already presented:

- SIP event packages can be used to distribute information and event notifications in a SIP network.

- Content Indirection is a privileged way to combine SIP and other protocols for e.g., redirecting a user to a web page (a service portal in the example), or retrieving large volume data (e.g. the content of the service registry).

User-based Service Routing

The SIP request that permits John to retrieve information from his service registry is routed to the right destination thanks to the following criteria: the request originated from John, it is addressed to John, and it happens to be a SIP SUBSCRIBE for a specific event package. Would one of these criteria be missing, the request would be routed elsewhere.

Similarly, the request that permits John to retrieve configuration information for service X is routed to the right server because it was originated from John, it is addressed to service X, and this is a SIP SUBSCRIBE for a specific event package.

Concerning Mary's request to access John's service profile, the routing is based on the fact that the request is addressed to John and does not originate from him. The fact that it originates from Mary, and that Mary is a special being for John may also impact the routing and make the request reach the right destination.

Finally, Mary is unable to access service X in spite of generating an adequate request addressed to the service. This is because the request originates from her, and her service profile does not include the right service routing information.

User-centric Service Architecture

Because John and Mary have a different service profile, the same SIP request issued by each of them can be routed to a different server. For instance, the SIP SUBSCRIBE permitting John to access Service X is routed according to John's service profile, while the same SIP SUBSCRIBE permitting Mary to access Service X (in case she is also subscribed to it) can be routed to a different server because it depends on Mary's service profile.

This mechanism, which permits the same service to be located in different application servers for different users permits:

- Service scalability to infinity. If you reach the vertical scalability of an application server, just deploy another one and populate service profiles for new subscribers with the address of the new server.

- The support of service variants for different market segments. For instance, simple or more sophisticated presence depending on the subscription.

- Multi-vendorship for a given service implementation, which is difficult to achieve in pre-IMS telco networks (e.g. MMS).

Implicit Addressing for Some Personal Services

In the example, the service registry is a personal service to John. The way for John to access the service registry is to issue a SIP request that is addressed to himself, and not to a specific location. The IMS service architecture, and more especially service routing based on John's service profile stored in the HSS does the trick.

A consequence of this approach is that John's client does not need to be provisioned with the location of the service registry to access its content. John's client can simply use one of John's Public Identities the client has been registered to IMS with.

Similarly, the application server hosting service X benefits from this implicit addressing, as it just has to generate a SIP request addressed to a user identity that has just been provisioned in order to publicize its availability to John.

Single User Identity / Multiple Services

The example shows that Mary can try to access John's service registry through the usage of one of his Public Identities. The same identity could be used to start a voice call with John, to initiate a gaming session, to send an IM to him, or to retrieve his presence.

Virtual Service Location

In the example, John, Mary or service X either use John's Public Identity or a Public Service Identity to access a specific service located on a specific server. The mapping between the identity and the actual location of the service is based on a service profile stored in an HSS.

Any change to the service profile may change the location, without any impact on the underlying addressing mechanism. It is therefore possible to change the location of a service over time, without impacting the way to access it. An example is when you want to switch to a new service implementation.

Network-based Service Authorization

In the example, routing of a service request to John's service registry and to Service X requires the existence of specific service routing information (Initial Filter Criteria) in the service profile associated to John.

This permits to directly link service authorization to SIP routing mechanisms in the IMS service architecture.

The example also showed that a service request that is not routed to the application server where the service is hosted can still be routed to alternative destinations, which may provide an appropriate response to the unauthorized service request. For instance, the alternate server can explain why the request was rejected, provide a limited trial version of the service, a pay per usage option, or simply propose the user to subscribe to the service and redirect it to a subscription web page.

Personalized and Shared Service Access

When John accesses Service X through his service profile, this access is personalized for John and points at an instance of Service X that can be highly customized according to John's preferences.

When Mary tries to access the same service using the same SIP request, this request is routed to a server according to service routing mechanisms associated to the service itself and not to Mary (as she is not subscribed to Service X). This access to Service X is shared with all other users that are not subscribed to Service X...

...Or at least a subset of them. The operator may actually route shared service requests to different application servers depending on the originator of the request. For instance, by checking the domain of the originator, the operator may define in Service X's service profile different service routing mechanisms for non-subscribed users that 1) are subscribers of this operator and may add this service to their service registry, 2) foreign users who are IMS subscribers of another operator, 3) service requests coming from the open Internet.

Integration of non-IMS services with IMS

In the example, the IMS-based automatic service discovery and configuration framework is applicable to both IMS and non-IMS services. This is, SIP and the IMS service architecture are used to get information about services, but the services themselves do not need to be accessed through SIP and the IMS service architecture.

This shows that IMS should be seen as a service framework, which does not necessarily require services to be implemented specifically for it. Non-IMS services can be integrated in this framework and benefit from its capabilities, without any impact on their implementation. Other examples of such integration will be presented in the future.

Service Anthropomorphism

Anthropomorphism: Attribution of human motivation, characteristics, or behavior to inanimate objects, animals, or natural phenomena

IMS service anthropomorphism is the ability for a service to act or be treated as an IMS user. I will come back on this concept, but here it can be seen that Service X publishes its availability by issuing a SIP request which could also be generated by one of John's client. Service X can either use its own public identity or impersonate John for this. Service X therefore has its own motivation and acts as if it was another IMS user.

Christophe

IMS Service Interaction Use Cases: Part 2

The last post presented 6 IMS service interaction use cases, which all had in common the fact that the initiator of the interaction was a client, typically a mobile handset or a PC soft client.

It is now time to consider service interactions initiated by an application server, as an IMS AS can support all the roles possible for a SIP entity, including the SIP User Agent (or client). This means that every SIP message generated or processed by an IMS client can also be generated or processed by an IMS application server. Consequently, you can take all the use cases described in the previous post, replace the client with an Application Server, and see if it makes sense. Alternatively you can keep on reading this post.

A preliminary question is: if a service on an application server can generate SIP messages, under which identity can it do it? There are two possibilities:
1) The service initiates the message under its own identity, which is a Public Service Identity (see previous post).
2) The service initiates the message under the identity of a user it serves, i.e. the service impersonates the user and acts on its behalf. This is acceptable because the application server is within the IMS security domain and under the control of the operator.

#7 John's service initiates interaction with John

The SIP message may be used to contact John himself or an application residing in a device associated to John. It may be targetted to any device or to a specific one. In this latter case, the service will use a Globally Routable User Agent URI (GRUU).

Service examples:
- Content push (SIP method can be MESSAGE, INVITE, REFER or PUBLISH)
- Deferred delivery of a stored message (SIP method can be MESSAGE or INVITE)
- Monitoring of user/application activity, e.g. is the user in a session? Is this application running? (SIP method is SUBSCRIBE)
- Access to local device information, e.g. what are the locally installed application? (SIP method is SUBSCRIBE)
- Initiation of stimulus based service control, i.e. user enters commands through typing on the keyboard or touching screen areas, the stimuli are translated into Keypad Processing Markup Language (KPML) and sent to the application for interpretation (SIP method is SUBSCRIBE, KPML semantic is tansported in NOTIFYs)

#8 John's service initiates interaction with Mary

This is basically the same as #7, except that the service is not associated to the user it interacts with and may even be from a different operator's domain. This is, a service offered by operator X can interact with a user or an application residing in a device of a user subscribed to operator Y.

For this kind of cross-user and potentially cross-domain service interaction, the service should act on behalf of the user it serves (John), so that identification and authorization can be performed adequately. Otherwise, the risk is that John's service, perceived as a total stranger from Mary's side, is authorized to very little if anything.

Service examples can be the same as for #7, except for deferred delivery messaging, which a priori makes sense only for an interaction between a service and the user it serves.

#9 John's service initiates interaction with another of John's services

Either acting with its own identity or on behalf of John, the service initiates a service interaction which is routed through the IMS service architecture to another application server hosting another of John's services.

This use case introduces the possibility for services associated to the same user to collaborate together using SIP, or to put it differently, for an IMS service to use another as an enabler. One can wonder why two IMS services would use SIP to interact when web services and SOA are just made for this. There can be several good reasons for this, including the fact that, as IMS applications, they naturally support SIP and they are just reusing an interface that has been defined for a client to application server usage. More especially, the enabling application will process a request from the requesting application just like it would process a request coming from an IMS client.

Service examples:
- John's session termination agent uses John's presence to decide how to process an incoming session attempt (SIP method is SUBSCRIBE)
- One of John's services issues a message to a group identifying a set of John's buddies. The second service is responsible for "exploding" the message distribution list to each of the intended users (SIP message is MESSAGE or INVITE)
- A service starts a conference call on behalf of John. The second service is the controller for the conference (SIP message is INVITE or REFER).
- One of John's services currently used by John automatically updates John's presence on his behalf (SIP method is PUBLISH)

#10 John's service initiates interaction with one of Mary's services

This use case is to #9 what #8 is to #7. John's service uses Mary's one as an enabler, and both can be located in different domains. Once again, John's service is likely to impersonate John in order for Mary's service to apply authorizations that are associated to John.

Service examples:
- An intelligent message routing service for John accesses Mary's presence to determine what is the best messaging mechanism to contact Mary (e.g. IMS messaging, SMS, MMS, email) right now or to send the message to all possible addresses associated to Mary (SIP method is SUBSCRIBE)
- A phone book service for John automatically retrieves all relevant contact information from Mary by quering her presence and/or other accessible information (SIP method is SUBSCRIBE)

Additional application server to application server use cases could be added, in which either the initiating or the recipient application server is located in the Internet. The use cases would be equivalent to those above, except that they could come with limitations essentially related to user authentication and end-to-end security (e.g. can the IMS application server trust the identity claimed by a request from the Internet?).

Believe or not, I am still not finished with IMS service interaction use case examples. The first 10 ones are simple peer-to-peer interaction use cases, using devices and application servers as peers. The next post will present use cases where application servers are inserted between peer-to-peer service interactions.

Christophe

IMS Service Interaction Use Cases: Part 1

In this post I will start to list some types of SIP interactions that are possible in an IMS architecture between service-related entities, i.e. devices and application servers in the network.

First, you need to know that there exist two types of identities in IMS:
- Public User Identities (IMPUs) are SIP URIs (sip:user@domain) or TEL URIs (tel:+3312345) that identify users.
- Public Service Identities (PSIs) are SIP URIs (sip:service@domain) or TEL URIs (tel:+3354321) that identity services, service features or user groups.

Now, based on standard 3GPP and SIP routing procedures, as well as the IMS service architecture based on service profiles stored in the HSS (see previous post), the following use cases are possible.

#1 John accesses a network-based IMS service he is subscribed to

The service may be explicitly identified via a PSI, or may implicitly be identified by the content of the SIP message (e.g. the message is a PUBLISH, it has a header called "event:" with the value "presence"). In this latter case, the SIP request is likely to be addressed to John himself (self-addressing).

John is a subscriber of the operator offering the service. He may be roaming or not.

Routing to the application server hosting the service is based on John's service profile in the HSS, and the fact that John originated the SIP service request.
This service routing mechanism ensures that John is authorized to access the service. If not, the service profile would not route the request to the application server. Other SIP routing mechanisms would then be used, which would either route the request to an Application Server handling non-authorized requests, or would reject the request if the target address cannot be resolved to an IP address.
It also ensures that the routing to the Application Server can be specific to John and different than the one for another user.

Service examples:
- John publishes new presence information (SIP method is PUBLISH)
- John discovers the services he is subscribed to (SIP method is SUBSCRIBE)
- John records a greetings message for his multimedia mailbox (SIP method is INVITE)
- John starts a Video on Demand session (SIP method is INVITE)
In all cases, John must be authorized to access the service. In the first three cases, the service is personal to John (John's presence, John's service registry, John's mailbox). In the last case, the service can be shared with others (VoD).

#2 John accesses a public network-based IMS service

The service must be explicitly identified via a PSI.

John might be a subscriber of the operator offering the service. He may alternatively be the subscriber of another operator, or simply a user accessing the service from the Internet.

The routing of the SIP request is based on the resolution of the PSI to an application server hosting the service. Either the PSI has a DNS entry, or the PSI is associated to a service profile in the HSS which determines that some SIP messages addressed to it have to be routed to this AS.

Service examples:
- Public news service (SIP method might be SUBSCRIBE or INVITE)
- Pay per view Video on Demand (SIP method is INVITE)
- Discussion Forum (SIP method is INVITE for messaging session)

#3 John accesses a network-based IMS service his girlfriend Mary is subscribed to

John might be a subscriber of the operator offering the service. He may alternatively be the subscriber of another operator, or simply a user accessing the service from the Internet.

The service is implicitly identified by the content of the SIP message, which is addressed to Mary. For instance, the SIP message might be a SUBSCRIBE addressed to Mary, which has a header called "event:" whose value is "presence".

The routing of the SIP message is based on the service profile associated to Mary in Mary's operator network and the fact that the request is terminating to Mary.

Service examples:
- Access to Mary's presence (SIP method is SUBSCRIBE)
- Access to Mary's user groups definitions (SIP method is SUBSCRIBE)
- Update of John's information in Mary's phone book (SIP method is PUBLISH)
These service requests are typically subject to authorization from Mary.

#4 John accesses a client-based IMS service from Mary

As the service is client-based, it might either be offered by the operator(s) of John and Mary, or by other service providers.

The service is implicitly identified by the content of the SIP message, which is addressed to Mary. For instance, the SIP message is an INVITE, and its session descriptor and/or a specific feature tag in the SIP message identifies a game.

Both John and Mary might be roaming.

The routing of the SIP message to Mary's devices is based on standard SIP routing procedures, possibly with forking and more sophisticated target determination mechanisms, in case Mary is reachable on multiple devices.

Service examples:
- Voice call (SIP method is INVITE)
- Multimedia session (SIP method is INVITE)
- Gaming session (SIP method is INVITE)
- Paul's checks if Mary is currently in a session (SIP method is SUBSCRIBE)

#5 John accesses a service located in one of his devices/servers connected to IMS

The service is located in a device or a server that belongs to John and is connected to the IMS network like an IMS user. It could also be accessible through the Internet. It might be offered by John's operator or by another service provider (possibly John himself).

The service is addressed through an identity perceived as a user identity from the IMS network. In a typical case the device or server is registered through John's identity. John therefore issues a SIP request addressed to himself, which will be routed to the device/server through normal SIP routing procedures. In order to route the request to a specific client (and avoid forking procedures), the request is likely to be addressed to the Globally Routable User Agent URI (GRUU) associated to the device or server. The GRUU permits to explicitly identify a device associated to the user.

Service examples:
- John retrieves a secured HTTP link to access private information on his PC (SIP method is SUBSCRIBE, uses the fact that IMS is a secured network and that John's identities are asserted both on the client and the server)
- John programs Windows Media Server to record a specific program (SIP method is PUBLISH)

#6 John accesses a service located in the Internet

The service might be explicitly identified by the SIP URI (kind of PSI) or might be implicitly identified in the SIP message, which is addressed to an Internet user.

The routing of the SIP message to the Internet is based on standard SIP routing procedures applied by the IMS core network.

Service examples:
- Access to presence located in the Internet (SIP method is SUBSCRIBE)
- VoIP session with Internet client
- Chat/IM with internet client

More use cases in the next post...

Christophe

Three Axes for IMS: #3 User Oriented Architecture

The Service Oriented Architecture (SOA) is an IT architecture that enables the creation of applications via the combination of loosely coupled and interoperable services. While there may be different implementations, typical SOA makes use of WSDL, BPEL and web services. Web 2.0 and Mashups are also linked to SOA.

SOA concepts and ideas are spreading very fast in the Telco industry. However, at the moment, few see a relationship between IMS and SOA, other than the fact that IMS (like the pre-IMS network(s)) can exhibit web services to an application layer implemented around SOA. In this vision, there are two clearly separated worlds: an IMS/SIP core network and a SOA/WS service network, the former integrating with the latter according to the latter's terms, i.e. by exposing its capabilities through web services.

My belief is that such a vision is very partial and totally ignores the capabilities of SIP and IMS for the delivery of services. SIP as a protocol, and IMS as a service architecture, can optimally integrate with and complement a SOA, by bringing a dimension that is currently missing to it and is fundamental: user orientation.

To understand how SIP and IMS can support a User Oriented Architecture (UOA), it is first important to realize that SIP is not only a very generic session control protocol, that can support application-level sessions (see previous entry). SIP also features an important set of non session-related extensions, which make it a very generic service control protocol. The most important of these extensions is certainly the concept of "event package", which is based on the methods SUBSCRIBE, NOTIFY, and PUBLISH. SIP-based Presence relies on event packages, which permit a user (or application) to access, monitor or modify presence information. However, presence is only the tip of the event package iceberg. There already exist numerous event packages, which permit, e.g. to monitor the activity of a user on a keyboard or the changes made to a user profile, or for a server to receive and interpret stimuli from a graphical user interface (e.g. the user touched this area, then entered this and that key). Event packages permit to create, update and distribute any type of event, data, and commands into a SIP network.

The user orientation of IMS is based on characteristics that are specific to the SIP protocol, and on others that belong specifically to the IMS service architecture.

In short, SIP addresses can relate to services, but are more usually associated to users. The IMS service architecture permits to route SIP requests to devices and to application servers based on the identity of the user. The routing of SIP requests to devices associated to the user is based on normal SIP routing procedures, while the routing of SIP requests to specific application servers is based on "service profiles" associated to each user and stored in the IMS user database, the HSS.

In practice, while SOA would permit an application to access the presence of user X by using a presence service with the identity of a user as parameter, SIP and IMS permit to access the presence of a user via the generation of a SUBSCRIBE which is addressed to the user identity. Instead of being routed to a unique presence service applicable to all users, the SIP request can be routed to an instance of the presence service which is specific to this particular user.

Such a reversal of the addressing and routing approach (service for SOA, user for SIP) is very important, as a request addressed to a SIP user address in IMS can reach a user, but also the devices associated to this user, and applications or application instances associated to this user, whether these applications reside in the network (e.g. presence) or in the device(s) of the user (e.g. a game).

Imagine a health monitoring device installed on the body of the user. A very convenient way for a centralized entity to access health indicators of the user and to monitor their changes over time would be to issue a SUBSCRIBE for a specific event package, and to address this SUBSCRIBE to the user itself. The same SUBSCRIBE addressed to different users will reach the health monitoring devices associated to each of them.

Now, think of all the potential applications of SIP event packages, add to it all the potential applications of the generic session control mechanisms of SIP. Think that there exist other SIP extensions of interest to add to the pack. Then, imagine the potential of a service architecture that combines both SOA and SIP/IMS principles...

Christophe