In April, I made a series of three posts on the infamous IMS Service Capability Interaction Manager (SCIM).
In the first one, I described the history of the concept in 3GPP. In the second one, I reviewed the features usually associated to the SCIM, mainly to say that I do not like them. Finally, I presented some of my ideas on what a SCIM could be, would it try to add value on top of the intrinsic capabilities of IMS.
As the SCIM is a topic that seems to interest a lot of people, I decided to add a little bit more meat on this subject.
You can find below three sides I made two years ago, when I first tried to formulate my vision of the SCIM. I think I still stand behind most of what is written there, and normally (hopefully) this should be consistant with my previous post on the topic.
Christophe
Stumble It!
29 commentaires:
Hi Christophe,
Many thanks for your slides on the "infamous" IMS SCIM.
Do you think the JSR 289: SIP Servlets -- Application Router capability will address the features you described in your slides?
Hi Gerry,
I may be wrong, but to my knowledge the functionality of the application router is not standardized and left for differentiated implementation.
It would definitely be an ideal candidate to implement the functionality I described. This functionality was discussed with some suppliers of Java EE platforms and maybe some will implement something that looks a little bit like this.
After all, maybe this is because I have been toying with these ideas for long, but I think this functionality should be straightforward for the supplier of a platform including SIP servlets. Maybe the more original part is the inclusion of a "user profile" component, which is closer to the IMS philosophy than the original application-centric concept of SIP servlet mapping rule.
I am a great supporter of SIP servlets (strongly integrated into a Java EE platform, and not standalone), but my neutrality can be challenged as I was involved in their original specification (extremely modest contribution actually).
Christophe
Hi Christophe,
I think that SCIM/Service Broker is a key element to provide an open and flexible service platform. However, as you said concerning the JSR 289 Application Router, it is not standardized and left to differentiated implementations. My concern is that the SCIM could have the same end. I mean that the efforts to standardize this functionnality in the 3GPP won't give anything concrete; and that the SCIM will be a vendor-proprietary solution. Don't you think that these vendor-specific solutions preclude an open and flexible service layer? Can the interactions issues be solved if there is no standards that adress how SCIMs "talk together"?
Hi Christophe,
Don't you think the SCIM could be a simple proprietary extension to existing IFCs of CSCFs?
Best
Hi Christophe,
First, thanks for a great blog.
How do you see the IM-SSF & SCIM interacting? Does IM-SSF require SCIM?
John.
Hi,
I will try to answer the three last comments at once.
To Sofiene...
I think that a fundamental question to answer about the future of telecommunications in general, and IMS in particular, is: how much standardization is too much?
Our industry likes to be guided through standards, but I think that a key for success is to transcend them.
In this context, I am not sure that the SCIM should be standardized more than what the JSR 289 Application Router defines.
The SCIM, as I see it, is part of the implementation of a service platform. I envision it as being transparent to the IMS core network on the one hand, and to application logic on the other hand. I do not see any need for two SCIMs to "talk together", being conscious that they are both SCIMs and they are talking with each other.
Another aspect is that there are not that many companies on the market, whose strategy is to deliver open service platforms for the telecom industry. I have decided not to name companies on this blog, but you can by yourself count the suppliers of Java EE, .NET or JAIN SLEE platforms..
In this context, I am pretty sure that if one of these companies comes with a SCIM functionality that stands out, then the others will align. If there is a need for this alignment to be formalized as a standard, this will then be done.
Overall, the most important is for the industry to agree on what IMS can be used for and how. This common understanding does not exist right now. Once this is done, if it is ever done, then we could think about what needs to be standardized and what should be left for innovation.
To the second comment...
If what you mean is that the SCIM could be part of the S-CSCF, then I disagree. I see the SCIM as an entity that belongs in the application layer, and the IMS application layer as a set of servers that are clearly distinct from the IMS core network. As I had the opportunity to write in the past, I see the IMS application layer as an advanced IT domain, in which the set of company that can bring value right now is not the same as those who can provide a good IMS core network. This is a subjective opinion, but this is my opinion.
Moreover from an architecture (and standard) perspective, there are big differences between an S-CSCF and an application server. For instance:
- An S-CSCF processes 100% of the SIP traffic of a user it serves, while an application server only processes the subset of the traffic that relates to its services.
- An S-CSCF is highly standardized, while an AS is naturally there for differentiation.
- An S-CSCF interacts with application servers, while the SCIM I see within an application server deals with applications.
Otherwise, if you mean that the SCIM might base its behavior on information that could be defined as an extension of iFCs, then yes, I agree this could be something that makes sense.
To the third comment...
The IM SSF is a gateway to a legacy IN or CAMEL application server.
Using a SCIM with an IM SSF would imply that the SCIM deals with voice-centric services, that are implemented in a circuit-switched environment and naturally applicable to circuit-switched calls.
It would also most certainly imply that the SCIM tries to coordinate the execution of these IN services, with services implemented on another technology, like a SIP AS.
I personally see little relevance for these scenarios, but my position is not the mainstream one at the moment.
This said, from an architecture perspective, one of the remote AS the SCIM I see could interact with could in theory be an IM SSF.
I do not know if this IM SSF would need the SCIM (or if the SCIM could really help this IM SSF), but I do not think my SCIM would need this IM SSF to have a reason to exist.
Christophe
Thank you Christophe for this answer and for this great blog.
...And many thanks to you Sofiene. You are greatly contributing to this blog through your comments and questions.
Christophe
Hi Cristophe,
I would also thank you for the SCIM and service inter-action issues you have been discussed.
I would also ask you a question regarding services interaction. None of the means in current iFC mechanism optimally resolve the situation when a User asks for adding a media to the same dialog. An additional INVITE with a new media will not cause re-evaluation of the iFC. In this case all the INVITE's will be sequentially routed though all the AS's and this may cause sometimes huge delay's.
I think that a secondary filter criteria was invented (but not used) in order to dynamically update STPs to resolve the problem I'm describing. By the way a Service Broker described in TR supports sFC. Currently 3GPP Rel. 7 defines DSAI tag in order at least partially resolve the issue.
What do you think about it?
Tks,
Andrei
Hi Andrei,
Thanks a lot for you comment.
For me, supporting multimedia sessions, with the possibility for a user to renegotiate the content at any time, is not an issue that should be solved by mechanisms related to the routing of SIP messages (more especially RE-INVITEs). Therefore, extending iFCs or loading the SCIM with this responsibility is not the solution.
The issue requires the adequate support of multimedia sessions in the application layer architecture.
Basically, instead of routing (or trying to re-route) SIP signalling to various silo application servers, each of which dedicated to a particular media type (e.g. voice, video, a game, an application, messaging), the S-CSCF should route the request to an application server that is designed to support multimedia.
Then, it just requires the right architecture, with the possibility to enrich the multimedia application server with new media types when appropriate/required.
I wrote a post on this topic on May 15th, which is called "Enabling Multimedia Communication". I just added a figure minutes ago to make it easier to understand. Please have a look.
Otherwise, to come back on sFCs, the concept simply does not work from a SIP perspective. I will address this topic in the next post dedicated to ISC from an AS perspective. There exist strict SIP routing rules, and a core one simply forbids to start routing SIP signalling to a new server right in the middle of an ongoing dialogue.
If you decide to do so, you simply break the end-to-end integrity of the protocol, which cannot be called SIP anymore. Maybe you can try to play with these rules inside an application server, but as a black box the AS has to be SIP compliant or you just kill IMS.
The architecture I propose (which has been at least partially specified in the IETF by more competent people than me) permits to address service-related SIP routing (iFCs, SCIM) and the support of multimedia sessions as two complementary but orthogonal issues.
Christophe
Hi Cristophe,
Thank you very much for your quick answer. To be honest I support your oppinion regarding SCIM/Service Broker (I'm just using an SB name to be in sync with 23.810 that my company is one of the supporting companies of). In order to accelerate the development of this TR we decided not to preclude any architectural option for Service broker (as a functional element) to be located.
I have another question. Speaking about multiple services chaining/inter-action don't you think that one of the possible architecture options may be that a Service Broker AS terminates a multi-media dialog and further invokes each application per media one by one that practically may be sending SIP INVITES for each media dedicated SIP AS?
BR
Andrei
Hi Cristophe,
FIY: Dynamic Service Activation Info (DSAI) tag is a 3GPP Rel.7 feature that is used by any AS in order for enable/disable any STP in the iFC. This feature is similar to sFC.
BR
Andrei
Hi Andrei,
I see the support of multimedia sessions via a SIP entity controlling the session, and able to add/drop media specific components (e.g. voice, messaging, game) through an appropriate control interface. SIP might be one of these, as you suggest, but I would not limit to it.
I would not say DSAIs are similar to sFCs. DSAIs permit application servers to activate/deactivate iFCs, without changing their nature. More especially they do not change the fact that an iFC is evaluated at the begining of a dialogue and only then. This means that activating a DSAI will not change the SIP traffic of ongoing dialogues. Basically, DSAIs permit an AS to say, from now on I want to be in the loop (or not) for future dialogues or standalone SIP transactions.
On the other hand, the original goal for sFCs (which have no real existence in the specifications) was for an AS to change the routing of SIP requests within an ongoing dialogue. Basically, the AS was invoked through an iFC, and could then within this dialogue tell the S-CSCF: I want to receive this or that signalling within this dialogue.
As I explained in my latest post on ISC seen from the IMS AS perspective (September 8th), the concept of sFC was inherited from IN and totally incompatible with the choice of SIP for ISC.
Christophe
stRUkg Your blog is great. Articles is interesting!
gUGAqE Nice Article.
jTFtJk Thanks to author.
Hello all!
Good job!
Nice Article.
actually, that's brilliant. Thank you. I'm going to pass that on to a couple of people.
Nice Article.
Thanks to author.
Hello all!
Thanks to author.
A99CN0 Hello all!
Nice Article.
Hi,
I think sFc's can be of some use after all. This may sound contrary to your views Christophe :) hehe
I have a situation here..
TS 23.218 gives an example of a voicemail service being imparted to a user who is in 'unregistered' state. That call flow is perfectly ok, as the control is passed on to the AS directly. What will happen if the user is registered and not answering the call? The terminating UE will return a 4XX/5XX error response, and on the basis of this response the S-CSCF will need to route the call to a Voicemail AS. I think SPTs can be defined for execution of a Voicemail sFc in this scenario!
Just a thought..i might be wrong.
Another example can be that of a Customized Ring Back Tone service(CRBT), where a tune is played on reception of 180 ringing? But this scenario is an 'early media' concept.
Hi Aayush,
Using iFCs, your use cases would be answered by the relevant AS being involved from the initial INVITE on, not only at the reception of the response.
In the case of the voicemail, the AS in question would not be the voicemail server itself, but an AS forwarding the call to the voicemail server in case the user does not answer.
Note that an sFC would need to be set by an AS invoked on the INVITE, so you cannot make the economy of involving an AS right from the begining, just for the sake of it.
You may argue that the iFC use case is not optimal from a traffic perspective, but just imagine that the AS hosts different services, some of which apply on the INVITE and not only the answer to the INVITE.
There are two things about the sFC issue:
1) Could it be useful in theory?
2) is it possible in reality
For 1), I would say that sFCs could in some cases reduce traffic to/from an AS, but funtionnally iFCs can support all use cases sFCs would support.
For 2), it is clear that involving a SIP entity only in responses to a request violates the basics of SIP routing. It is therefore not a good thing for a SIP compliant system.
One way around would be to have a kind of sFC equivalent within an AS: the AS itself receives both the requests and the answers to them, but within the AS some logic is executed only for some requests.
Christophe
I tried this and it fits my needs.
http://voipsipsdk.com/Download.aspx
Post a Comment