Tuesday, June 26, 2007

Public Service Identity Service Patterns

In this post, I will try to present some potential usage of Public Service Identities (PSIs) for the delivery of IMS services.

Services to the World

PSIs were standardized for this, but it might be useful to highlight it: PSIs permit an operator to provide services that are accessible from any SIP network.

This means that the IMS Lantern chat room from the previous post, or any content identified through a PSI, is potentially accessible to all IMS subscribers of the world, whether their subscription is a fixed, mobile, cable, or converged one.

This also means that the same service is accessible from non-IMS networks with SIP connectivity like the Internet.

Combination of Private/Restricted and Public Access to a PSI

The previous post might have given the impression that a PSI can either be accessed by a happy few or by everybody.

Actually, this does not have to be. A PSI can be accessed in one way by a happy few, and in another way by all the others, and the way a PSI is accessed can determine the logic that is executed to process the corresponding SIP request in the IMS application layer.

Private/Restricted access to a PSI is determined by the service profile associated to the originator of the SIP request addressed to the PSI (i.e. the service profile of the user includes one or several initial filter criteria that relate to the PSI and permit to route the request to an application server).

What happens for users who initiate a SIP request to the PSI and do not have a PSI-aware service profile?

The IMS core network will try to route the SIP request anyway, and then there are two cases:
1) There is no way to match the PSI to a physical address, i.e. there is no service profile associated to the PSI, and it is not defined in any DNS (or ENUM) server or in the HSS. In that case, the PSI is really accessible by a happy few.
2) There is a "public" PSI routing mechanism, i.e. one of the three mechanisms described in the previous post. In that case, the PSI is also accessible to everybody. The public access mechanism may route the request to another application server or to the same one as the private/restricted access procedure. In any case, it is possible for an application server to determine how the SIP request was routed to the application server (i.e. either as an originating or a terminating request), and consequently to apply a different logic for each case.

Automatic Service Discovery and Configuration

I already gave an example of this mechanism with the automatic service discovery and configuration service pattern. In this example, John is subscribed to Service X, and consequently benefits from the restricted access configuration information associated to the service. His girlfriend Mary is not subscribed to Service X. If she issues a request addressed to sip:ServiceX@operator.com in order to retrieve service X's configuration information, the request will be routed to an alternative service logic, which will deny access to the information.

Restricted Access for Management of Public User Groups

Another example would correspond to a user group identified by the PSI sip:Friends_of_IMS@operator.

Anybody can use this PSI to send an instant message to members of the group, access their presence information, or start a multimedia session with them (public access to the PSI). All these services are accessed through the initiation of an adequate SIP request addressed to the PSI (i.e. MESSAGE, SUBSCRIBE for presence event package, INVITE). Routing to the relevant application server is based on the service profile associated the PSI (i.e. MESSAGEs go to messaging server, SUBSCRIBEs for presence event package go to the resource list server, INVITEs go to the multimedia conferencing server).

On the other hand, only a few users can manage the user group, i.e. add/remove users to it. This implies that SIP requests that permit to access and modify the definition of the user group (SUBSCRIBE, PUBLISH for a group management event package) are restricted to a limited set of people. These people will have their service profile defined in such a way that their management requests to the sip:Friends_of_IMS@operator PSI will be routed to the application server managing the user group. The same management requests issued by a non authorized user will not be routed to any application server and will be rejected by the IMS core network (the service profile associated to the PSI does not define any routing for PUBLISH and SUBSCRIBE requests related to the group management event package).

Differentiated Access to Content (see figure, click to enlarge)

The third example is illustrated by the picture at the top. The PSI sip:This_Content@operator identifies a specific content (e.g. a video) that can be accessed through a SIP session initiated by the user.

Four application servers serve the same PSI.

A and B serve the subscribers of the operator who are authorized to access the content. Access to these application servers is based on the service profiles associated to each subscriber. The service profiles associated to subscribers in the partition #1 route the service request to A, while service profiles associated to subscribers in the partition #2 route the service request to B. Service logic on A and B delivers the content.

C serves the subscribers of the operator who are not authorized to access the content. The service profile associated to the PSI determines that all requests originating from users whose IMPU's domain is the one of the operator shall be routed to C. The service logic on C may show a preview of the content and propose the user to subscribe to the content.

D serves subscribers of other operators and users from the Internet. The service profile associated to the PSI determines that all requests originating from users whose IMPU's domain is not the one of the operator shall be routed to D. The service logic on D may propose the user to pay for viewing the content.

It would be possible to further discriminate between users trying to access the content. For instance, the service profile associated to the PSI could determine that SIP requests which do not include a P-Asserted-Identity header (i.e. requests originated from a non-IMS network) should be routed to an application server E.



Anonymous said...

Hi Christophe,

I agree with you on the possibilities service profiles offer operators to provide a service in a different way depending on, for example, who is asking for it. But at first glance I don't find it necessary to have several aplication servers, one for each of the potential user types, as long as there are not significant changes in its behaviour.

That would be the case of a broadcasting service that depending on subscription status was provided with time or quality restrictions. Has it been foreseen any way to indicate the AS such a situation, so that the same service could always be routed to the same AS?

In other words, is there any way to specify parameters through the ISC reference point at service invocation?


Christophe Gourraud said...

Hi Paul,

The possibility to distribute the same service on different application server instances, and this transparently to IMS users and their clients, is an interesting capability.

However, I agree that this capability may not have the same interest for all services. This is not the silver bullet, just an interesting capability among others.

Personally, I do not necessarily see the possibility to have different service logic applying to different users as the main interest of this approach. I will come back on this in future posts, but one of the great values I see in the IMS service architecture is the possibility to chain services together. In order for this chaining to be optimized, it is better to try and locate the services to be chained in the same application server. Instead of application servers dedicated to a service, this would lead, for some services, to application servers dedicated to sets of users, and hosting a set of tightly coupled services for them. Several instances of the application server would then deal with different subsets of users, having a different service profile. The example I am giving on my new post (More on The SCIM!) corresponds to this case of service co-location.

Concerning your example, if the differences between users depend on their subscription, this can be handled by the service profile associated to each. Users benefiting from a premium access to the content, would have their service profile route the request to a premium AS. Others to another AS.

In order to assist decisions on an application server, there is quite a lot of information that exists in SIP requests, either in their IETF version or with the IMS extensions. For these latter, see my post from May on the content indirection service pattern.

In a bigger picture, you may also imagine inserting in the SIP signalling path a service logic whose role, among others, would be to select the most adequate content server based on various criteria. You can see that in the same post.


Jack Chrysler said...
This comment has been removed by the author.
Viagra Online said...

PSIs is one of the best programs that this people have created because there are people who don't have time to to this kind of procedures.

Metro Ethernet said...

It is only an issue to which we devote their time and attention to understand and learn more about this, actually I am in total agreement with what is written here and now I can only say good job guys continue doing its work

viagra without prescription said...

This is a very good point of view, I think that it can be made and it can be achievable.

escorts palma said...

So, I don't actually believe this will work.

Anonymous said...

buy xanax overnight delivery names of generic xanax - xanax vs vicodin effects

Anonymous said...

Yοuг οwn repοrt features confiгmed beneficial tο me.
It’s extremely eԁucаtіonal and you rеally arе naturally reаllу knоωleԁgeablе in this area.

Yοu have еxpοsed my eye to
vаrious thoughts аbοut this ѕpecific subject using inteгеsting and soliԁ cοntent.

my blog post ... ativan