IMS Service Interaction Use Cases: Part 3

The last two posts presented service interaction use cases which applied end-to-end, between service entities consisting of clients and application servers. They distinguished between cases where the initiator of the service interaction was a client and others where it was an application server.

These simple use cases can be made more interesting by the addition of application servers between the endpoints, in order to add value to end-to-end service interactions. All these application servers make use of the IMS service architecture and sit on the IMS Service Control (ISC) reference point. This said, there can still be multiple variants for the way the services on the application servers behave, leading to a vast array of service possibilities.

In this post I will try to introduce these service variants, at least those I can think of.

The service may either act as a SIP proxy (a) or as a back-to-back user agent (B2BUA) (b). Without going into details, the proxy behavior permits little control on the end-to-end SIP interaction and generally applies to services that simply monitor SIP traffic or perform actions which do not directly impact the end-to-end service interaction (e.g. the service initiates a new service interaction as a consequence of the one it is proxying). On the other hand, acting as a B2BUA is more adequate for services which intend to control the end-to-end service interactions (e.g. changing a leg, modifying session description).

The service either inserts itself in a service interaction initiated by a peer (i.e. a client or application server use case from previous posts) (c), or the service is itself the initiator of the service interaction between the peers (d). For instance, the service initiates a session between John and Mary.

The service may be tranparent to the peers involved in the service interaction (e). This is the case when the service only adds value to an otherwise peer-to-peer service interaction. Alternatively the service may be visible, i.e. it appears in SIP signalling as the recipient or initator of SIP messages via its Public Service Identity (PSI) (f). In this case the service is offered as such to the peer, and its implementation happens to be a facade (or a frontend), which makes use of other services or connect to other peers to deliver its features. For instance, a multimedia content service identified via a PSI actually aggregates individual media components accessible via SIP as part of its delivery session. Note that SIP is only one of the protocols that the facade service can use towards backend services.

The service may either apply to one peer of the end-to-end service interaction (e.g. John) (g) or be shared by all participants in the peer-to-peer relationship (h). In the former case the service is personal to a user and may be customized specifically for him/her, while in the latter case the service is shared between two or more users. A typical example of a shared service is one that supports the multi-party nature of a SIP service interaction, e.g. a multimedia conference server, or a chat room for IMS.

The service may either be the single intermediary between the peers (i), or may be chained with other services (j). An example of chained services on a service interaction path of type messaging (SIP MESSAGE) could be: an anti-spam service, an anti-virus service and an archive service. Another example applied to VoIP would be the chaining of a voice call continuity (VCC) server responsible for switching between WiFi/IMS and cellular/circuit-switched during the voice call, with a voice application server supporting typical telephony features for the user.

In the case where a service is part of a chain, there might be two variants: either the service is independent of the other services further down in the chain (k), or it has been developed with the knowledge of the intended/possible signalling path and with the intention to have an impact on services further down in the chain (l). The examples given for (j) belong to the first category, as each service is independent from the others. An example of a service of the second category would be one that forwards an intended SIP interaction to one PSI or to another, thus impacting the service chain. Another example would be a service that adds or removes a parameter in the SIP message in order to trigger or inhibit a service or feature somewhere down the path.

Finally, a service may systematically act as an intermediary in the peer-to-peer service interaction (m) or may sometimes decides to take over the role of the peer for the service interaction (n). In the VoIP example given for (j), the VCC server will always act as an intermediary, while the voice application server may sometimes act as an intermediary when it decides to let call setup happen, or as a peer if it decides to reject the call attempt on behalf of the user it serves.

Maybe with a little bit more thinking I could find more variants in order to go up to the letter "z". The point I am trying to make is that there are too many variants for involving application servers in the middle of peer-to-peer SIP service interactions for me to even try coming up with a complete list of use cases.

However, in future posts where I will try to give examples of potential IMS services, I will certainly refer to the framework defined in this post and the previous two.

Christophe