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