re: IMS GuideGÇ£Most interestingly, the "Profile" schema is designed to hold "transparent" application data also associated with the Public ID used to identify the concerned party fopr any given request/dialog. In this sense, the "Profile" extends beyond the schema and application defined by the 3GPP into areas which overlap with the schema's for enablers like Presence, Group List Management and even other non-standard applications. The fine-grained access to these related Profile parts is not facilitated by any of the 3GPP application usages of DIAMETER, but is made possible through a combination of SIP and XML Configuration Access Protocol.GÇ¥
Emphasis added above (bolding) is mineGǪ
I remember a few carrier deployments of LDAP a number of years back wherein what the carrier was deciding should be in the schema was not completely able to support the application, in this case a large scale Voice Messaging application supporting the carrierGÇÖs residential customers GÇô we are talking millions of users and many hundredGÇÖs of calls per second for the large scale deployment we were doing.
Case in point: user password. Should it be in the GÇ£directoryGÇ¥ maintained by the HSS? Sure it should, customer support (ala OSS) is going to interact with user during a phone call for help when they forget that password and want it reset.
Should the application get the password from the HSS? Sure, but what about encryption of the password, i.e. stored in the GǣclearGǥ; stored encrypted; and where is the type and logic surrounding the access methods? GǪ
This detail could never get agreed to during the previous implementation discussions surrounding a carrier wide LDAP directory for services and I suspect it will not be agreed to during the GÇ£HSS acting as a brokerGÇ¥ philosophy discussions in a pure IMS deployment.
End of the day? GÇô a directory (in the past proprietary, today probably LDAP) local to the application to support a complete set of fields necessary to support the application (one such as Voice Messaging) while the subset of this set is maintained on the HSS. And for performance reasons in large deployments, this LDAP directory is probably in RAM with disk recovery features upon server failure. It may even have separate LDAP search mechanisms with cut-down directory sizes so that even GÇ£in RAMGÇ¥ searches can perform to the level that proprietary solutions can do today. In the old days, one might have called this index-sequential, but this is only a description at the macro level, since LDAP mechanisms must still be supported, if only to take advantage of the rest of the open-source paradigm.
In this way, hashing of the user password (or any other encryption method) could be implemented locally along with the logic resident in the application itself. There are other examples, of data that no one would want in the HSS, but they would, by definition be information on the user and should almost by definition be in the HSS.
At the end, implementation decisions around performance or usage will perhaps force this to be stored locally, in LDAP, and maintained there under application control, because it has to be accessed very quickly and/or it may not be used anywhere else except that application.
re: IMS GuideAll this is well and good, but I'm curious how billing and settlement would work in such an environment. The writeup indicates that new service providers with no network could be formed to just offer a service layer. But of course, to access the service layer, the subscriber must go over someone's network. Would the subscriber also need to separately buy access through someone else's network (kind of how I can access my corporate VPN over my cable mode today - but only if I buy cable modem service first)? Or would the service provider establish a series of realtionships where they provided compensation to the carrier network for each session terminated on their service infrastructure (like how the IXCs pay the ILECs for terminating calls on their local networks today)?
What are the thoughts on the business model opportunities? And are the standards in place to support billing and CDR (the way Bellcore AMA format is used in the PSTN)?
re: IMS GuideWhat's this business about ITU-T having a role in IMS? Their NGN fokus group pretends to cover it but even its own members question the assumption that their work should be based on 3GPP spec's.
Anyone got any real proof that ITU-T should be listed here as "involved" (=actually doing real standards making work)
re: IMS Guideoptodoofus asks: "..I'm curious how billing and settlement would work in such an environment.."
All of this stuff, including the relationships between an access provider and an end users service provider, is covered by the 3GPP core specs for IMS and this is part of the reason why it's so interesting for many service providers because it is one of the fe VoIP systems that you can actually make money with by selling service.
re: IMS GuideThe article states that a service provider can supply a personal calendar service. Can anyone think of an application that is more suitable to being provided by a user-owned device than his personal calendar.
Actually there is one, service providers do offer speed dial services from their switches. Instead of storing speed dials locally on a $20 telephone and activating a number with a labeled button, the service provider stores them on its switch and forces the subscriber to remember a 1 or 2 digit code for each. On top of that it charges $4 a month for the service.
Both these examples show the futility of supplying what are naturally local services with a centralized architecture. There is nothing novel about this architecture. Centralized service logic is just the AIN rehashed. When with that zombie finally return to the grave?
Thanks and Regards
Shalini
If you have some idea, please mail me at [email protected]
Borna.
Emphasis added above (bolding) is mineGǪ
I remember a few carrier deployments of LDAP a number of years back wherein what the carrier was deciding should be in the schema was not completely able to support the application, in this case a large scale Voice Messaging application supporting the carrierGÇÖs residential customers GÇô we are talking millions of users and many hundredGÇÖs of calls per second for the large scale deployment we were doing.
Case in point: user password. Should it be in the GÇ£directoryGÇ¥ maintained by the HSS? Sure it should, customer support (ala OSS) is going to interact with user during a phone call for help when they forget that password and want it reset.
Should the application get the password from the HSS? Sure, but what about encryption of the password, i.e. stored in the GǣclearGǥ; stored encrypted; and where is the type and logic surrounding the access methods? GǪ
This detail could never get agreed to during the previous implementation discussions surrounding a carrier wide LDAP directory for services and I suspect it will not be agreed to during the GÇ£HSS acting as a brokerGÇ¥ philosophy discussions in a pure IMS deployment.
End of the day? GÇô a directory (in the past proprietary, today probably LDAP) local to the application to support a complete set of fields necessary to support the application (one such as Voice Messaging) while the subset of this set is maintained on the HSS. And for performance reasons in large deployments, this LDAP directory is probably in RAM with disk recovery features upon server failure. It may even have separate LDAP search mechanisms with cut-down directory sizes so that even GÇ£in RAMGÇ¥ searches can perform to the level that proprietary solutions can do today. In the old days, one might have called this index-sequential, but this is only a description at the macro level, since LDAP mechanisms must still be supported, if only to take advantage of the rest of the open-source paradigm.
In this way, hashing of the user password (or any other encryption method) could be implemented locally along with the logic resident in the application itself. There are other examples, of data that no one would want in the HSS, but they would, by definition be information on the user and should almost by definition be in the HSS.
At the end, implementation decisions around performance or usage will perhaps force this to be stored locally, in LDAP, and maintained there under application control, because it has to be accessed very quickly and/or it may not be used anywhere else except that application.
What are the thoughts on the business model opportunities? And are the standards in place to support billing and CDR (the way Bellcore AMA format is used in the PSTN)?
Anyone got any real proof that ITU-T should be listed here as "involved" (=actually doing real standards making work)
All of this stuff, including the relationships between an access provider and an end users service provider, is covered by the 3GPP core specs for IMS and this is part of the reason why it's so interesting for many service providers because it is one of the fe VoIP systems that you can actually make money with by selling service.
Actually there is one, service providers do offer speed dial services from their switches. Instead of storing speed dials locally on a $20 telephone and activating a number with a labeled button, the service provider stores them on its switch and forces the subscriber to remember a 1 or 2 digit code for each. On top of that it charges $4 a month for the service.
Both these examples show the futility of supplying what are naturally local services with a centralized architecture. There is nothing novel about this architecture. Centralized service logic is just the AIN rehashed. When with that zombie finally return to the grave?