In the past, I had the opportunity to write three posts (here and there and there) about the 3GPP concept of Communication Service. These posts were written in the heat of possibly major IMS-defining decisions being taken, in order to warn about some risks related to some options. Time has passed and the concept is now (nearly totally) specified in IMS. In this post I will describe Communication Services and how they can be used by operators.
Definition
According to TS 23.228, "an IMS communication service is a type of communication defined by a service definition that specifies the rules and procedures and allowed medias for a specific type of communication and that utilises the IMS enablers."
Examples of Communication Services are OMA Push To Talk over Cellular (PoC) or OMA SIMPLE Instant Messaging (also called IMS Messaging in 3GPP specifications).
In other words a Communication Service is a set of communication media and the rules that govern the possible (i.e. permitted) transactions between them. For instance, OMA SIMPLE Instant Messaging only permits SIP sessions to include messaging components. Trying to upgrade a messaging session into a voice session is not part of the OMA SIMPLE IM service, and can be considered as a violation of the OMA SIMPLE IM Communication Service.
A Communication Service is identified in SIP signalling through an IMS Communication Service Identifier (ICSI). The format as well as an example of ICSI can be found in TS 24.229:urn-xxx:3gpp-service.ims.icsi.mmtel (Multimedia Telephony).
An IMS application can use a Communication Service to be delivered to the end-user. For instance, an application could push content to a user by using the OMA SIMPLE IM Communication Service. Such an application can be identified in SIP signalling through an IMS Application Reference Identifier (IARI) for which TS 24.229 also provides an example: g.3gpp.app_ref="urn%3Aurn-xxx%3A3gpp-application.ims.iari.game-v1". Note that IARIs are only meaningful for IMS clients and are totally ignored by IMS core network entities. This is why I will not mention them much in the following.
The list of Communication Services associated to a user is provisioned in the service profile of the user in the HSS. This list is used by the S-CSCF for its processing of SIP requests. It is also provisioned in IMS clients for usage.
The IETF draft describing the necessary SIP extensions to support the concept of Communication Service states that all the information required for a network to understand the service requested by a user should be derivable from the SIP request (e.g. by looking at the SDP and the request-uri in a SIP INVITE), without the need for an explicit identifier like an ICSI. It accordingly states that the ICSI is a way for the network to save computational resources required to inspect the SIP request. I would tend to disagree with this analysis. First, the ICSI does not only define how a user wants to start the session, it also explicitly defines that the user will not try or may not be allowed to later renegotiate the session in a way that is not specified by the service definition. Moreover, an IMS S-CSCF will not make the economy of analyzing the request, as it will have to ensure that the ICSI and both the initial and subsequent INVITEs in the session are coherent one with the others. Therefore, the usage of Communication Services will rather increase the need for computational resources in the S-CSCF than lower it.
What Communication Services could have been
The company which introduced the concept of Communication Service in 3GPP had a quite radical proposal of how it would be used:
- The usage of a Communication Service would have been mandatory in all SIP requests initiated by an IMS client. A side-effect was that all IMS applications would have had to rely on a Communication Service, thus strongly limiting opportunities for IMS services.
- Two SIP clients would not have been able to set up a session together if they did not share the same Communication Service. This would have implied that a client supporting OMA SIMPLE IM and a client able to support both messaging and voice within the same SIP session would not be able to establish a session together, even if they shared a common media component permitting to communicate. This would also have implied that a SIP client without any knowledge of IMS-specific ICSIs would not have been able to set up sessions with an IMS client.
- Usage of Communication Services totally relied on the IETF-specified Contact and Accept-Contact headers (in which ICSIs and IARIs would have been included as media feature tags), thus using a standard IETF header in a non-standard way and adding to interoperability issues with non-IMS SIP clients.
Would have they been accepted, these proposals would have raised important barriers to service innovation in the IMS domain, and would have caused huge interoperability problems between IMS and non-IMS clients, de facto creating a walled garden out of IMS.
A side effect is that the concept would have created a two-tiered IMS application layer, with application servers supporting (standardized) Communication Services at the bottom, and application servers supporting applications making use of Communication Services at the top. The lower tier would typically have consisted of standardized services implemented as black boxes supplied by classical network equipment suppliers, and the (rather power-less) upper tier by open platforms provided by IT suppliers (more or less what you can find in a pre-IMS telecommunications network, with OSA/Parlay usually defining the frontier between the two layers). This two-tiered architecture would have been reproduced within IMS clients.
However, in their current state, due to the involvement of the IETF and the consensus imposed by companies which did not endorse this original view, 3GPP specifications are quite far from this.
General benefits of Communication Services
Communication Services can be useful to all operators, even if their strategies clearly differ, as long as each operator has options about how it wants to use them. Representing an operator, I had in the past the opportunity to discuss the issue with the supplier promoting the concept. After expressing my concerns about it and hearing their arguments in its favor, I told them: "Communication Services are fine with me as long as, as an operator, I can use them when I see an interest for it and not use them when I do not see any". Since then, this possibility to use Communication Services a la carte is what has been specified.
These usage options start at the IMS client, which may but is not mandated to insert an ICSI (and possibly IARI) in a SIP request it generates. They also exist further in the processing of SIP signalling by the IMS core network, as you will see below.
But first, let us consider the aspects of Communication Services that may appeal to all operators.
Communication Services can make the life of operators easier in some aspects.
Put a label on a service, transport this label end-to-end in SIP signalling, and you get a practical handle for charging (more especially when several operators and/or transit network suppliers are involved in the end-to-end communication), QoS and policy control, and to set your initial filter criteria for involving ASs supporting the service. However, this does not mean that the IMS core network should ease on its processing. For instance, current IMS specifications permit to charge a session based on both accounting information related to SIP signalling (e.g. this is a messaging session with a beginning and an end) and media level information (e.g. this is indeed messaging that goes through). It would be risky for an operator to assume that because an ICSI states that the session is about messaging and messaging only, this is actually the case. If so, Communication Services could be a great weapon for fraud.
The usage of ICSIs in users' service profiles to determine the routing to application servers can be of great interest as I will illustrate now. Imagine that an IMS client initiates an INVITE for messaging while the operator has deployed OMA IM SIMPLE, OMA CPM and OMA PoC V2, which all may start with such an INVITE. The operator may face the tricky challenge to decide to which application server the request should be routed in the case where the user is subscribed to at least two of these services. By placing an ICSI identifying the service it wants to use, the IMS client indicates to the network that this is this service and not this one that it intends to use.
Passed these basic, different handling of communication services are possible, which map to different strategies.
The two sections below describe these potential differences. What is common between both is that an IMS client may insert an ICSI in a SIP request it generates, but this is not a mandatory standard procedure. When a client wants to use a communication service (and possibly a specific application making use of it), it inserts the ICSI in a header called P-Preferred-Service. It may also include the ICSI and IARI in Accept-Contact headers (currently 3GPP is not clear about the exact procedure for this).
Communication Services for advanced user control
The S-CSCF serving a user (the originating one for requests initiated by the user, the terminating one for requests received by the user) may be mandated to insert an ICSI in all the requests it receives. For doing so, it compares the request with the list of ICSIs provisioned in the user's service profile for a match. This ICSI is inserted in a P-Asserted-Service header created by the S-CSCF. In the case where the IMS client created a P-Preferred-Service header, it is removed by the S-CSCF, and it is possible that the ICSI inserted by the S-CSCF and the original ICSI are different. The S-CSCF will also insert an ICSI in SIP requests which did not have any P-Preferred-Service header.
When an ICSI inserted by a user does not match the request (e.g. the user inserted an OMA SIMPLE IM ICSI and actually has an SDP body for a voice session) or the ICSI in the SIP request is not in the list of authorized ICSIs in the user's service profile, or the S-CSCF cannot map the request to any of the ICSIs authorized for the user, the S-CSCF may simply reject the request.
Once a SIP session has started, the S-CSCF may also reject renegotiations of the session that do not correspond to the service definition (e.g. a user tries to upgrade an OMA SIMPLE IM session to voice).
More liberal usages of Communication Services
An operator may inhibit all the restrictive behavior of the S-CSCF by not provisioning any ICSI in the service profile of a user. In this case, an IMS client can still insert an ICSI in a SIP request (the ICSI may have been provisioned in the client or may be hard-coded) and the ICSI may still be used to route the request to an application server, for charging, QoS or policy control, but the S-CSCF cannot insert an asserted ICSI and reject any request. Note that such an ICSI cannot be trusted by the core network but an AS can be used for this purpose.
If an operator provisions ICSIs in the service profile of the user, it can still decide that the S-CSCF should not reject requests as in the specification this decision is left to the operator's policy. The S-CSCF will just insert the P-Asserted-Service header.
Finally, even if the most restrictive S-CSCF behavior could apply, its potential impossibility to unambiguously associate one ICSI to a request (e.g. the user is authorized to use an OMA SIMPLE IM and an OMA CPM ICSI while both services can start with a messaging session) mandates it not to insert any ICSI in the request, de facto inhibiting its restrictive processing.
Interoperability with non-IMS cients
The IETF solved the potential interoperability issues between IMS and non-IMS clients by clearly discriminating between, on the one hand the usage of ICSIs and IARIs in the SIP Accept-Contact and Contact headers, which comply with the IETF procedures for a SIP client to declare its capabilities to a network (so-called callee capabilities) and for a SIP client to indicate preferences or instruct a SIP network about how the request it generated should be routed/forked (so-called caller preferences), and on the other hand the usage of ICSIs for network-centric usage within an IMS network (definition of two 3GPP specific headers: P-Preferred-Service and P-Asserted-Service).
Based on 3GPP procedures, a non-IMS client may receive a SIP request from an IMS client that includes a P-Asserted-Service header, but this header will simply be ignored and will not impact processing in the non-IMS client.
ICSIs and IARIs populated in the Accept-Contact header do not create interoperability problems either, as this header can (optionally) be used by a client to help selecting an application to be contacted but is primarily aimed at SIP proxies, instructing them about how to route the request.
However, there might still be a case where an IETF-compliant usage of Accept-Contact may prevent an IMS client to initiate a session with a non-IMS client: if the Accept-Contact header that includes the ICSI or IARI also includes both the "explicit" and "require" parameters, it instructs the SIP proxy not to route the request to a SIP client that did not explicitly declared its support of the ICSI (or IARI). As non-IMS clients are very likely not to being even aware of IMS ISCIs and IARIs, the IMS client would never be able to set up a session with them (however, the funny thing is that a non-IMS client would be able to set up a session with an IMS one).
At the moment, 3GPP did not decide on how ICSIs and IARIs should be used in Accept-Contact, but the risk I just mentioned is explicitly stated as a note in TS 24.229, which indicates that some companies are very wary about the issue. In any case, there is a need to clarify this aspect, and this might have to be done either globally (e.g. an IMS client shall not use these two parameters for ICSIs, but it might use them for some IARIs if the corresponding application requires it), or service per service, unless it is left to the decision of the operator.
Potential issues with ICSIs
To be used for advanced control, ICSIs require additional provisioning in the service profile of the user (HSS) as well as in IMS clients.
ICSIs now make the S-CSCF service aware, as it has to be able to compare ICSIs to SIP requests and SDP bodies into session initiation and session re-negotiation requests. At best this may imply a reconfiguration of the S-CSCF each time a new communication service is introduced (standardized or operator-specific). At worst this may imply an upgrade of the S-CSCF.
The S-CSCF processing of ICSIs (checking if a request matches the ICSI in it, trying to find an ICSI for a request without any, checking if session renegotiation matches what is permitted for an ICSI) will add to resource consumption and end-to-end delays. In the case where ICSIs do not significantly simplify other procedures of the IMS core network (and I do not think they will), this is a pure loss for core network characteristics. This might be a minor factor, but it could also be an important one once IMS traffic grows in important proportions.
Any future for Communication Services used for control?
In its current state of specification, the concept of Communication Service can be used both by liberal operators and by operators wishing to exert a strong control over their customers.
In the liberal approach, ICSIs can be used to facilitate the routing of service requests to the right application server(s). No constraining behavior of the S-CSCF will be mandated, and while ICSIs can be used as a convenient way to identify a service (for instance in charging records), they will not significantly help the task of core network entities in their processing (e.g. generating accurate charging records).
In the controlling approach, ICSIs can be used as a means to check that users only access (typically silo) services they are explicitly authorized to use, and that they cannot escape control (at least at SIP level) during the session.
Maybe the controlling approach will be used by some operators. However, considering the facts that ICSIs do not only come with benefits and that users may be led to draw comparisons between operators with a strong controlling and a more liberal approach, I am not sure right now that Communication Services are promised to a bright IMS future. Future will tell.
Christophe
References:
Definitions and requirements: TS 23.228 chapter 4.13
Detailed procedures by IMS client: TS 24229 chapters 5.1.1.2.1 (declaration of supported ICSIs as callee capabilities at registration), 5.1.2A.1 (generation of SIP request), 5.1.2A.2 (reception of SIP request)
Detailed procedures by S-CSCF: TS 24.229 chapter 5.4.3.2 (originating requests), 5.4.3.3 (terminating requests)
Communication Services in Service Profiles: TS 29.228 Appendix B (B.2 and B.2.1A)
Showing posts with label Communication Service. Show all posts
Showing posts with label Communication Service. Show all posts
Wednesday, April 9, 2008
Monday, June 4, 2007
IMS Communication Services: Latest News
Last week, the 3GPP CT plenary meeting decided to align on the IETF approach for the handling of communication services. This can be seen in a Liaison Statement to the IETF available on the 3GPP web site.
The worst has been avoided for now, as the alternative proposal (which lost) had two important drawbacks:
1) It reused a standard IETF mechanism (feature tag used in the Accept-Contact header) with a different, 3GPP-specific semantic.
2) It made the concept of communication service directly manipulated by IMS clients, which could have a huge impact on interoperability aspects with non IMS clients, and would have driven the implementation of mobile handsets for the years to come.
The IETF alternative limits the mandatory identification of communication services within the IMS network, which interprets SIP signaling generated by clients and derives the communication service ID from it.
Easier to Eventually Get Rid of It
As a network centric concept, the communication service ID is less intrusive and easier to control by operators (compared to the case where it would be client-centric). It can certainly be used for early IMS silo services, and then be discarded when more multimedia services are deployed.
This can therefore be a short-term concept serving short-term requirements.
The Concept Could Be Useful Even in the Long Term
Moreover, it could evolve into something actually interesting in the context of a more progressive vision of IMS services.
At the moment, the S-CSCF uses initial filter criteria in order to dispatch SIP requests to the application layer. The evaluation of filter criteria implies an analysis of the SIP requests (method, direction, content).
As the result of this analysis is not documented in the SIP request forwarded to the application server, the application server (potentially the SCIM into it) needs to perform a new and somehow redundant analysis of the SIP request in order to determine which services should be invoked.
A communication service ID header could permit an identification of the initial filter criteria that led to the forwarding to the application server, that could be used by the AS as part of its own analysis of the incoming SIP request.
Obviously, in this context the ID would not identify a service, but rather a set of criteria associated to a SIP request, and which can be used as information (among other) to invoke service logic in application servers.
Still Some Risks
From the LS to the IETF you cannot determine that the risk for communication services creating an IMS walled garden and limiting potential for service innovation has been averted for good.
The LS explicitly mentions the need to comply with requirements written in TS 23.228. The problem is that the most dangerous aspects of communication services are described in TS 23.228 (see last post).
On the other hand, the IETF could also rightly underline that TS 23.228 includes incompatible requirements, as I tried to explain in my last post. More especially, some requirements describing a 3GPP-specific concept of communication service directly conflict with others asking to preserve SIP capabilities and interworking with non-IMS networks.
In any case, one of the important requirements in TS 23.228 is that it should be possible for an IMS client or an IMS network not to make use of communication services. This optionality should ensure holes in the hypothetical walls of the IMS garden.
I am therefore reasonably confident that things will turn out in the right direction, once the IETF identifies these incompatibilities and proposes to resolve them by removing the dangerous requirements. The CT plenary decision from last week seems to express the importance that 3GPP places into being interoperable with other SIP networks.
Christophe
April 2009 update: the concept of Communication Service as finally specified is described here.
The worst has been avoided for now, as the alternative proposal (which lost) had two important drawbacks:
1) It reused a standard IETF mechanism (feature tag used in the Accept-Contact header) with a different, 3GPP-specific semantic.
2) It made the concept of communication service directly manipulated by IMS clients, which could have a huge impact on interoperability aspects with non IMS clients, and would have driven the implementation of mobile handsets for the years to come.
The IETF alternative limits the mandatory identification of communication services within the IMS network, which interprets SIP signaling generated by clients and derives the communication service ID from it.
Easier to Eventually Get Rid of It
As a network centric concept, the communication service ID is less intrusive and easier to control by operators (compared to the case where it would be client-centric). It can certainly be used for early IMS silo services, and then be discarded when more multimedia services are deployed.
This can therefore be a short-term concept serving short-term requirements.
The Concept Could Be Useful Even in the Long Term
Moreover, it could evolve into something actually interesting in the context of a more progressive vision of IMS services.
At the moment, the S-CSCF uses initial filter criteria in order to dispatch SIP requests to the application layer. The evaluation of filter criteria implies an analysis of the SIP requests (method, direction, content).
As the result of this analysis is not documented in the SIP request forwarded to the application server, the application server (potentially the SCIM into it) needs to perform a new and somehow redundant analysis of the SIP request in order to determine which services should be invoked.
A communication service ID header could permit an identification of the initial filter criteria that led to the forwarding to the application server, that could be used by the AS as part of its own analysis of the incoming SIP request.
Obviously, in this context the ID would not identify a service, but rather a set of criteria associated to a SIP request, and which can be used as information (among other) to invoke service logic in application servers.
Still Some Risks
From the LS to the IETF you cannot determine that the risk for communication services creating an IMS walled garden and limiting potential for service innovation has been averted for good.
The LS explicitly mentions the need to comply with requirements written in TS 23.228. The problem is that the most dangerous aspects of communication services are described in TS 23.228 (see last post).
On the other hand, the IETF could also rightly underline that TS 23.228 includes incompatible requirements, as I tried to explain in my last post. More especially, some requirements describing a 3GPP-specific concept of communication service directly conflict with others asking to preserve SIP capabilities and interworking with non-IMS networks.
In any case, one of the important requirements in TS 23.228 is that it should be possible for an IMS client or an IMS network not to make use of communication services. This optionality should ensure holes in the hypothetical walls of the IMS garden.
I am therefore reasonably confident that things will turn out in the right direction, once the IETF identifies these incompatibilities and proposes to resolve them by removing the dangerous requirements. The CT plenary decision from last week seems to express the importance that 3GPP places into being interoperable with other SIP networks.
Christophe
April 2009 update: the concept of Communication Service as finally specified is described here.
Saturday, June 2, 2007
IMS Communication Services: Uncut Version
In my last post, I presented a light version of the 3GPP concept of Communication Service, which focuses on the identification in SIP signalling of the service a user intends to use.
However, the standardization of communication services started nearly 18 months ago, and from contributions to the subject you can draw a quite precise picture of what IMS services could be, would all the proposed requirements be approved by 3GPP and implemented in products.
The text below written in italic is my own rephrasing of requirements that were proposed for communication services (I usually try to stay close to the original wording). All these requirements can be found in public documents: contributions to 3GPP SA2, text in chapter 4.13 of TS 23.228 7.x.x, a draft submitted to the IETF, and contributions to 3GPP CT1.
A communication service is the aggregation of one or several media components. The rules that govern this aggregation are implemented by service logic. A service description specifies the possible behavior and states, e.g. the allowed media combination and state transitions. If an IMS client would like to perform a change in a session which is not part of the service definition, it shall establish a new session.
The lack of support of true multimedia making use of intrinsic SIP capabilities is not a defect of early IMS silo services, that needs to be fixed as soon as possible. This is a feature of 3GPP introduced in R7. Such a requirement could install silos in standard compliant IMS deployments for many years.
The approach is clearly restrictive. IMS clients are placed under control, and service logic is implemented to prevent them from accessing non allowed multimedia features.
Multimedia may be possible, but through multiple parallel sessions. Such an approach may imply a complex interface towards the end-user, who would need to explicitly control parallel sessions. Alternatively, it would require the implementation of a ad-hoc client able to hide the multiplicity of sessions to the end-user. This latter option would have the "merit" to both clearly identify what is needed (i.e. a single service session) and demonstrate that communication services prevent to do it in a natural way (i.e. a single SIP session). Simulating multimedia sessions through multiple more restricted sessions would certainly incur complexity and costs. No need to say that such strange SIP clients would be very different from non-IMS SIP clients, thus re-inforcing IMS as a world apart.
Communication services are either standardized (e.g. push to talk) or proprietary and specific to an operator or an enterprise.
Every SIP message initiated by an IMS client must include a requested IMS Communication Service. A session can only be started between two clients if they share the same IMS Communication Service. Within the client, the Communication Service ID is used to dispatch the message to the correct application.
The first statement seems to imply an opening of the concept to non standardized communication services including, why not?, more innovative and multimedia ones.
However, this openness looks very artificial when you see that communication service IDs must be part of all SIP signalling and directly govern the ability to start a session between two clients.
Let's take an example.
An operator decides to introduce a new communication client, enabling the user to freely switch between messaging/chat and voice communication inside one session. In a normal SIP world, such a client can establish sessions with voice-only clients, as well as with messaging-only clients. The only restriction is that the transition to another media component is not possible with these peer clients. The new service is therefore both compatible with legacy clients and with new or more sophisticated multimedia clients introduced by this and other service providers, in the IMS, in the enterprise or in the Internet.
In the wonderful world of communication services, the situation is different. The operator must create a new communication service ID for the service. Because this communication service ID is different from the voice-only and messaging-only ones, it is not possible to start a session with legacy clients. Session setup will also fail with (a priori) compatible clients introduced by other operators but using a different ID. As a consequence, the service will have great difficulties to take off as it is likely that most attempts to set up a session with it will fail. It is certainly better for the operator to wait for standardization to introduce the service.
As the concept of communication service does not exist outside of IMS, the mandatory nature of its usage makes interoperability with non IMS clients virtually impossible. Consequently, the new service will not even be able to setup sessions with clients that are not subject to communication service limitations.
The hypothetical adoption of the requirements described above would therefore both create an IMS walled garden and make very difficult the introduction of innovative and operator-specific multimedia services within this walled garden.
Added-value applications deployed over IMS must make use of Communication Services. When a client intends to access such an application, the SIP signalling must include two identities: the identity of the application and the identity of the communication service it uses.
There is plenty to say about this proposal...
First it gives the impression of a willingness to favor service innovation. However, in a context where communications services consist of voice, push to talk over cellular (i.e. voice without the quality) and messaging, how different can these applications be from those that can make use today of circuit switched voice, SMS and MMS?
The approach seems to enforce the usage of silos mimicking pre-IMS services, as the only way to deliver non standardized services in the IMS. Non standardized services need to follow the rails (pipes?) strictly and arbitrarily defined by standardization, and which are more or less the same as before. Any multimedia service that would make use of standard (e.g. RTSP) or application-level protocols that are not part of a communication service definition are outlawed by 3GPP standards.
You may imagine that new communication services, permitting more innovative services will be introduced in the future. In 3GPP R8? R9? In any case, this is likely to be in several years from a product perspective. Strictly controlled, innovation has to follow the roadmap defined by 3GPP and the companies that control it.
Another interesting aspect of this approach is that it creates a two-tiered IMS application layer in both IMS clients and in the network. This layered architecture is explicit in a figure introduced in TS 23.228 chapter 4.13.
The bottom part of this layer consists of the standardized communication services, which are very telco centric and demand carrier grade characteristics to control undisciplined clients. I guess classical network equipment providers are the best placed to deliver these as black boxes.
The upper part is the innovative one, the more IT layer. It has to rely on the lower part, certainly through a set of interfaces like OSA/Parlay or web services. As I wrote above, room for innovation is strictly limited.
In past posts, I described my belief that for the benefit of the industry, the whole IMS application layer should belong to advanced and open IT platforms, benefiting from the huge community of Java developers and the ability for people with good ideas to easily and rapidly develop them.
Communication services as described in these requirements would lead to a marginalization of this IT layer and its tight control by the telco one below. It would actually recreate the current telecom situation, in which there are so few ammunitions to create innovative services that innovation can hardly take place.
If you consider that there might be an ongoing fight between old school NEPs and IT companies (or NEPs clearly embracing an IT strategy) for the control of the future telecom application layer, communication services look like a powerful weapon for the former against the latter.
Communication services should not adversely impact interoperability with external SIP and circuit-switched networks. It shall be possible for IMS clients and IMS networks to support communication that do not make use of a communication service ID. The usage of communication service identifiers shall not restrict the inherent capabilities of SIP.
All these requirements can be found in TS 23.228 together with some of the seemingly contradicting requirements above. This shows that some companies in 3GPP (vendors, operators) do not support the idea of an IMS walled garden and are afraid of the potential consequences of communication services on the ability of IMS to innovate and to be open to other domains.
This is an important thing to take into account. 3GPP consists of a variety of visions which sometimes oppose each other. It would be wrong to say that 3GPP as a whole supports the most extreme definition of communication services, and I would tend to think that, well informed on the potentially negative effects of these concepts, the great majority of 3GPP companies would not endorse them.
Christophe
April 2009 update: the concept of Communication Service as finally specified is described here.
However, the standardization of communication services started nearly 18 months ago, and from contributions to the subject you can draw a quite precise picture of what IMS services could be, would all the proposed requirements be approved by 3GPP and implemented in products.
The text below written in italic is my own rephrasing of requirements that were proposed for communication services (I usually try to stay close to the original wording). All these requirements can be found in public documents: contributions to 3GPP SA2, text in chapter 4.13 of TS 23.228 7.x.x, a draft submitted to the IETF, and contributions to 3GPP CT1.
A communication service is the aggregation of one or several media components. The rules that govern this aggregation are implemented by service logic. A service description specifies the possible behavior and states, e.g. the allowed media combination and state transitions. If an IMS client would like to perform a change in a session which is not part of the service definition, it shall establish a new session.
The lack of support of true multimedia making use of intrinsic SIP capabilities is not a defect of early IMS silo services, that needs to be fixed as soon as possible. This is a feature of 3GPP introduced in R7. Such a requirement could install silos in standard compliant IMS deployments for many years.
The approach is clearly restrictive. IMS clients are placed under control, and service logic is implemented to prevent them from accessing non allowed multimedia features.
Multimedia may be possible, but through multiple parallel sessions. Such an approach may imply a complex interface towards the end-user, who would need to explicitly control parallel sessions. Alternatively, it would require the implementation of a ad-hoc client able to hide the multiplicity of sessions to the end-user. This latter option would have the "merit" to both clearly identify what is needed (i.e. a single service session) and demonstrate that communication services prevent to do it in a natural way (i.e. a single SIP session). Simulating multimedia sessions through multiple more restricted sessions would certainly incur complexity and costs. No need to say that such strange SIP clients would be very different from non-IMS SIP clients, thus re-inforcing IMS as a world apart.
Communication services are either standardized (e.g. push to talk) or proprietary and specific to an operator or an enterprise.
Every SIP message initiated by an IMS client must include a requested IMS Communication Service. A session can only be started between two clients if they share the same IMS Communication Service. Within the client, the Communication Service ID is used to dispatch the message to the correct application.
The first statement seems to imply an opening of the concept to non standardized communication services including, why not?, more innovative and multimedia ones.
However, this openness looks very artificial when you see that communication service IDs must be part of all SIP signalling and directly govern the ability to start a session between two clients.
Let's take an example.
An operator decides to introduce a new communication client, enabling the user to freely switch between messaging/chat and voice communication inside one session. In a normal SIP world, such a client can establish sessions with voice-only clients, as well as with messaging-only clients. The only restriction is that the transition to another media component is not possible with these peer clients. The new service is therefore both compatible with legacy clients and with new or more sophisticated multimedia clients introduced by this and other service providers, in the IMS, in the enterprise or in the Internet.
In the wonderful world of communication services, the situation is different. The operator must create a new communication service ID for the service. Because this communication service ID is different from the voice-only and messaging-only ones, it is not possible to start a session with legacy clients. Session setup will also fail with (a priori) compatible clients introduced by other operators but using a different ID. As a consequence, the service will have great difficulties to take off as it is likely that most attempts to set up a session with it will fail. It is certainly better for the operator to wait for standardization to introduce the service.
As the concept of communication service does not exist outside of IMS, the mandatory nature of its usage makes interoperability with non IMS clients virtually impossible. Consequently, the new service will not even be able to setup sessions with clients that are not subject to communication service limitations.
The hypothetical adoption of the requirements described above would therefore both create an IMS walled garden and make very difficult the introduction of innovative and operator-specific multimedia services within this walled garden.
Added-value applications deployed over IMS must make use of Communication Services. When a client intends to access such an application, the SIP signalling must include two identities: the identity of the application and the identity of the communication service it uses.
There is plenty to say about this proposal...
First it gives the impression of a willingness to favor service innovation. However, in a context where communications services consist of voice, push to talk over cellular (i.e. voice without the quality) and messaging, how different can these applications be from those that can make use today of circuit switched voice, SMS and MMS?
The approach seems to enforce the usage of silos mimicking pre-IMS services, as the only way to deliver non standardized services in the IMS. Non standardized services need to follow the rails (pipes?) strictly and arbitrarily defined by standardization, and which are more or less the same as before. Any multimedia service that would make use of standard (e.g. RTSP) or application-level protocols that are not part of a communication service definition are outlawed by 3GPP standards.
You may imagine that new communication services, permitting more innovative services will be introduced in the future. In 3GPP R8? R9? In any case, this is likely to be in several years from a product perspective. Strictly controlled, innovation has to follow the roadmap defined by 3GPP and the companies that control it.
Another interesting aspect of this approach is that it creates a two-tiered IMS application layer in both IMS clients and in the network. This layered architecture is explicit in a figure introduced in TS 23.228 chapter 4.13.
The bottom part of this layer consists of the standardized communication services, which are very telco centric and demand carrier grade characteristics to control undisciplined clients. I guess classical network equipment providers are the best placed to deliver these as black boxes.
The upper part is the innovative one, the more IT layer. It has to rely on the lower part, certainly through a set of interfaces like OSA/Parlay or web services. As I wrote above, room for innovation is strictly limited.
In past posts, I described my belief that for the benefit of the industry, the whole IMS application layer should belong to advanced and open IT platforms, benefiting from the huge community of Java developers and the ability for people with good ideas to easily and rapidly develop them.
Communication services as described in these requirements would lead to a marginalization of this IT layer and its tight control by the telco one below. It would actually recreate the current telecom situation, in which there are so few ammunitions to create innovative services that innovation can hardly take place.
If you consider that there might be an ongoing fight between old school NEPs and IT companies (or NEPs clearly embracing an IT strategy) for the control of the future telecom application layer, communication services look like a powerful weapon for the former against the latter.
Communication services should not adversely impact interoperability with external SIP and circuit-switched networks. It shall be possible for IMS clients and IMS networks to support communication that do not make use of a communication service ID. The usage of communication service identifiers shall not restrict the inherent capabilities of SIP.
All these requirements can be found in TS 23.228 together with some of the seemingly contradicting requirements above. This shows that some companies in 3GPP (vendors, operators) do not support the idea of an IMS walled garden and are afraid of the potential consequences of communication services on the ability of IMS to innovate and to be open to other domains.
This is an important thing to take into account. 3GPP consists of a variety of visions which sometimes oppose each other. It would be wrong to say that 3GPP as a whole supports the most extreme definition of communication services, and I would tend to think that, well informed on the potentially negative effects of these concepts, the great majority of 3GPP companies would not endorse them.
Christophe
April 2009 update: the concept of Communication Service as finally specified is described here.
Wednesday, May 30, 2007
Danger! IMS Communication Services
You may not be aware of it, but the future of IMS is maybe being defined right now, in 3GPP, as a debate is raging around the concept of Communication Services and how it should be supported in SIP signalling.
If you need a practical exercise for navigating through the 3GPP web site, just access the directory for the ongoing CT Plenary meeting (TSG CT twice, then meeting #36, look for Communication Services).
In the worst case scenario, IMS may really become this telecommunications monster some have already wrongly denounced (at least until now).
For the second time since the begining of IMS standardization, the IETF had to raise its voice and is now warning 3GPP about the risk of a dangerous divergence between the IMS and non IMS SIP worlds. The first time, during the 2002-2003 winter, the danger was averted. Will it be the same this time?
Let's start by presenting Communication Services.
The concept of Communication Services was introduced in the 3GPP Release 7 of IMS by one of the most important network equipment providers.
There have been proposals for several requirements defining a new concept, but at the moment consensus could only be found on a subset of them. This subset is already very dangerous to those like me who believe that the hypothetical success of IMS is tightly linked to its ability to provide the best services to end-users and to freely interoperate with other IP networks, more especially the Internet.
In this post, I will introduce this light version of the concept. In another one I will present the more complete version, in case all proposed requirements would be included.
Communication Services: Light Version
The light version of Communication Services answers a concern shared by many operators, and clearly expressed by the GSM Association: the need to clearly identify IMS services for inter-operator settlement and charging.
The reasoning is the following.
An issue with SIP is that the protocol is so generic that it is hard to determine which service a user intends to use when its client issues a particular SIP message. For instance, SIP INVITE is used to setup a session. In a circuit-switched network, the ISUP equivalent is used to set up a voice call. In early IMS, a SIP INVITE may be used to start a voice session, but also a push to talk session, or a messaging session, or a videosharing session. It could also be a gaming session, an application sharing session, or a multimedia session combining several of the preceding components and/or others.
In this context, how do you want to interconnect different networks, possibly with transit ones in the middle, and still agree on how the money is shared between all parties? In other words, how can you preserve the telephony business model with IMS?
The simple (simplistic?) solution is to tag every initial or standalone SIP message with an ID identifying the service it requests.
A SIP INVITE starting a push to talk session will include a service identifier for push to talk. The same for a voice session, a messaging session, etc.
This reasoning leads to some issues, that have been described in this excellent IETF draft by Jonathan Rosenberg.
I will use my own words to describe some of these.
What is a Service?
The telecommunications industry has a silo thinking about communication services, which frontally clashes with the capabilities of the SIP protocol, and by ricochet with the interest of end-users.
In this silo thinking, push to talk is a pure walkie talkie service. It starts as walkie talkie, continues as walkie talkie, and ends as walkie talkie. And this until a standardization body decides that another communication medium is added to the definition of the push to talk service.
Similarly IMS session-based messaging is a service which is purely about messaging, from begining to end (OMA Converged IP Messaging is trying to change this). And so on.
However, SIP can support a much more powerful communication concept.
First, session setup follows a peer to peer negotiation process, during which the initial content of the session can be agreed on. Then, at any time, the session can be renegotiated between the peers. For instance, a messaging component can be replaced by a voice one, or be complemented with a game.
It is a fact that early IMS communication services (e.g. push to talk, voice) have been implemented as silos.
It can also be claimed that the push to talk feature tag that appears in a push to talk INVITE is already a de facto service identity for the push to talk service. But this is wrong: it is never written in push to talk specifications that this tag is a service identity and must be used as such (the specifications mandate to use the tag according to its IETF semantic).
The definition of a service identity as a standard IMS concept implies that the content of a session is frozen from the begining, and limited to the standard definition of the corresponding service. It also implies that this identity is used in many locations in the IMS infrastructure, for instance for service authorization, for service charging, for applying specific policies, as the element used to trigger specific service logic, as the element used to invoke a specific application in an IMS client, as an element used for agreement of the session setup between two IMS clients, etc.
Without the service identity concept, you can consider that early IMS service silos can be fixed through a re-engineering of service implementation. As IMS is still in early deployment stages, this fix could happen relatively smoothly for most.
With the concept duly standardized and impacting a large part of the IMS infrastructure implementation (core network, application layer, OSS/BSS, IMS clients), an evolution from silos to a more horizontal approach will be more complex, slow and costly. It may also not be standard compliant, if you want to go too fast.
Who Wins with this Approach?
Certainly some network equipment vendors, who can sell as many black boxes as they manage to define silo communication services. If a feature of these black boxes is to ensure that the service definition is not violated by SIP clients (i.e. "it is forbidden to upgrade a messaging session to a voice one, you naughty customer!"), the black boxes need to be involved in all IMS sessions, and therefore need to support all the carrier-gradeness characteristics which permit to sell them at outrageous prices.
Certainly not the end-user, who is condemned to an artificially limited communication experience, while it may experience a radically different one each time a non-IMS SIP client comes to its attention in the Internet. The temptation to bypass the telecom communication services might be big (why would you hesitate to have much better for a fraction of the price?).
What about operators?
They enjoy the comfort to keep on making business as usual (at least as long as there is some) and the relief not to have to reinvent their way of thinking about telecommunications in the few years to come. As a side effect, they gain expensive communication pipes, as they artificially limit the services they offer to their customers, and have to pay a high price for this, with the hope that they will charge a lot in return (does this ring a familar bell?).
Risks of an IMS Walled Garden
The draft from Jonathan Rosenberg is focusing on one particular issue: the usage of service identities by SIP/IMS clients.
If an IMS client is mandated to indicate the communication service it uses when it issues SIP signaling, and if this communication service ID is used by the peer client to accept the session, you run into potentially big interoperability problems with clients which are not ready for this (i.e. non IMS clients).
The approach would require that SIP clients share a knowledge of the communication services they can use. It also makes much more difficult for two clients to negotiate a compromise session if the optimal one is not possible.
In effect, the risk is to simply prevent communication between IMS and non IMS clients. Something that may be needed, if you do not want your IMS users to know that there is another SIP world in which communication does not have to be artificially limited.
The side effect is also to limit the set of IMS communication services to what the pace and imagination of telecom standardization and vendors can deliver. Good luck.
The picture I am drawing is quite dark, but I think it is not far from the potential IMS reality in front of us, would 3GPP decide to go the wrong way.
Christophe
April 2009 update: the concept of Communication Service as finally specified is described here.
If you need a practical exercise for navigating through the 3GPP web site, just access the directory for the ongoing CT Plenary meeting (TSG CT twice, then meeting #36, look for Communication Services).
In the worst case scenario, IMS may really become this telecommunications monster some have already wrongly denounced (at least until now).
For the second time since the begining of IMS standardization, the IETF had to raise its voice and is now warning 3GPP about the risk of a dangerous divergence between the IMS and non IMS SIP worlds. The first time, during the 2002-2003 winter, the danger was averted. Will it be the same this time?
Let's start by presenting Communication Services.
The concept of Communication Services was introduced in the 3GPP Release 7 of IMS by one of the most important network equipment providers.
There have been proposals for several requirements defining a new concept, but at the moment consensus could only be found on a subset of them. This subset is already very dangerous to those like me who believe that the hypothetical success of IMS is tightly linked to its ability to provide the best services to end-users and to freely interoperate with other IP networks, more especially the Internet.
In this post, I will introduce this light version of the concept. In another one I will present the more complete version, in case all proposed requirements would be included.
Communication Services: Light Version
The light version of Communication Services answers a concern shared by many operators, and clearly expressed by the GSM Association: the need to clearly identify IMS services for inter-operator settlement and charging.
The reasoning is the following.
An issue with SIP is that the protocol is so generic that it is hard to determine which service a user intends to use when its client issues a particular SIP message. For instance, SIP INVITE is used to setup a session. In a circuit-switched network, the ISUP equivalent is used to set up a voice call. In early IMS, a SIP INVITE may be used to start a voice session, but also a push to talk session, or a messaging session, or a videosharing session. It could also be a gaming session, an application sharing session, or a multimedia session combining several of the preceding components and/or others.
In this context, how do you want to interconnect different networks, possibly with transit ones in the middle, and still agree on how the money is shared between all parties? In other words, how can you preserve the telephony business model with IMS?
The simple (simplistic?) solution is to tag every initial or standalone SIP message with an ID identifying the service it requests.
A SIP INVITE starting a push to talk session will include a service identifier for push to talk. The same for a voice session, a messaging session, etc.
This reasoning leads to some issues, that have been described in this excellent IETF draft by Jonathan Rosenberg.
I will use my own words to describe some of these.
What is a Service?
The telecommunications industry has a silo thinking about communication services, which frontally clashes with the capabilities of the SIP protocol, and by ricochet with the interest of end-users.
In this silo thinking, push to talk is a pure walkie talkie service. It starts as walkie talkie, continues as walkie talkie, and ends as walkie talkie. And this until a standardization body decides that another communication medium is added to the definition of the push to talk service.
Similarly IMS session-based messaging is a service which is purely about messaging, from begining to end (OMA Converged IP Messaging is trying to change this). And so on.
However, SIP can support a much more powerful communication concept.
First, session setup follows a peer to peer negotiation process, during which the initial content of the session can be agreed on. Then, at any time, the session can be renegotiated between the peers. For instance, a messaging component can be replaced by a voice one, or be complemented with a game.
It is a fact that early IMS communication services (e.g. push to talk, voice) have been implemented as silos.
It can also be claimed that the push to talk feature tag that appears in a push to talk INVITE is already a de facto service identity for the push to talk service. But this is wrong: it is never written in push to talk specifications that this tag is a service identity and must be used as such (the specifications mandate to use the tag according to its IETF semantic).
The definition of a service identity as a standard IMS concept implies that the content of a session is frozen from the begining, and limited to the standard definition of the corresponding service. It also implies that this identity is used in many locations in the IMS infrastructure, for instance for service authorization, for service charging, for applying specific policies, as the element used to trigger specific service logic, as the element used to invoke a specific application in an IMS client, as an element used for agreement of the session setup between two IMS clients, etc.
Without the service identity concept, you can consider that early IMS service silos can be fixed through a re-engineering of service implementation. As IMS is still in early deployment stages, this fix could happen relatively smoothly for most.
With the concept duly standardized and impacting a large part of the IMS infrastructure implementation (core network, application layer, OSS/BSS, IMS clients), an evolution from silos to a more horizontal approach will be more complex, slow and costly. It may also not be standard compliant, if you want to go too fast.
Who Wins with this Approach?
Certainly some network equipment vendors, who can sell as many black boxes as they manage to define silo communication services. If a feature of these black boxes is to ensure that the service definition is not violated by SIP clients (i.e. "it is forbidden to upgrade a messaging session to a voice one, you naughty customer!"), the black boxes need to be involved in all IMS sessions, and therefore need to support all the carrier-gradeness characteristics which permit to sell them at outrageous prices.
Certainly not the end-user, who is condemned to an artificially limited communication experience, while it may experience a radically different one each time a non-IMS SIP client comes to its attention in the Internet. The temptation to bypass the telecom communication services might be big (why would you hesitate to have much better for a fraction of the price?).
What about operators?
They enjoy the comfort to keep on making business as usual (at least as long as there is some) and the relief not to have to reinvent their way of thinking about telecommunications in the few years to come. As a side effect, they gain expensive communication pipes, as they artificially limit the services they offer to their customers, and have to pay a high price for this, with the hope that they will charge a lot in return (does this ring a familar bell?).
Risks of an IMS Walled Garden
The draft from Jonathan Rosenberg is focusing on one particular issue: the usage of service identities by SIP/IMS clients.
If an IMS client is mandated to indicate the communication service it uses when it issues SIP signaling, and if this communication service ID is used by the peer client to accept the session, you run into potentially big interoperability problems with clients which are not ready for this (i.e. non IMS clients).
The approach would require that SIP clients share a knowledge of the communication services they can use. It also makes much more difficult for two clients to negotiate a compromise session if the optimal one is not possible.
In effect, the risk is to simply prevent communication between IMS and non IMS clients. Something that may be needed, if you do not want your IMS users to know that there is another SIP world in which communication does not have to be artificially limited.
The side effect is also to limit the set of IMS communication services to what the pace and imagination of telecom standardization and vendors can deliver. Good luck.
The picture I am drawing is quite dark, but I think it is not far from the potential IMS reality in front of us, would 3GPP decide to go the wrong way.
Christophe
April 2009 update: the concept of Communication Service as finally specified is described here.
Friday, April 27, 2007
Does IMS Create a New Walled Garden?
Definitly no!
IMS was made from the begining to permit end-to-end SIP signalling between IMS and non-IMS endpoints, and if the non-IMS endpoint does not support SIP, the IMS service architecture permits an easy integration of protocol gateways.
Wikipedia defines a walled garden as follows: A walled garden, with regards to media content, refers to a closed set or exclusive set of information services provided for users (a method of creating a monopoly or securing an information system). This is in contrast to providing consumers access to the open Internet for content and e-commerce.
I have seen in surveys that many operators believe that IMS will permit them to create a new walled garden, and they like the idea very much, even defining it as one of the main advantages of IMS.
But this is not the case, and in this post I will try to clarify some points related to this, as well as give examples of how 3GPP always intended to keep IMS open to non-IMS networks, and more especially the Internet.
I think that creating new walled gardens is not a strategy that will be sustainable for operators in the years to come. Concerning IMS, I believe that the extent of its eventual success will be proportional to the traffic generated between it and the Internet. An IMS with very low traffic to and from the Internet would be an IMS which has failed to deliver any added value to end-users, who would bypass it to directly access services in the Internet. On the other hand, high traffic would means that IMS is integrally part of the place where everything happens.
3GPP IETF Dependencies List
3GPP maintains a long list of dependencies on IETF specifications. Some may interpret it as the sign that IMS is full of telco-specific extensions to the IETF protocols it uses (mainly SIP and Diameter).
This would be totally wrong. 3GPP essentially reuses specifications elaborated within the IETF space. Moreover, more often than not, IMS has been an essential driver to improve and extend SIP-related specifications in the IETF. Without the push from the whole telco industry, I doubt the IETF SIP community would be as dynamic as it is.
The reason for this list is that it is essential for 3GPP specifications to be based on stable RFCs, and not drafts that have an expiration time and may once simply disappear. The list permits 3GPP to clearly identify the IETF drafts that are of importance for IMS, and to speed up their progress towards RFC status.
IMS Proprietary SIP Extensions
In the course of standardizing the IMS core network, 3GPP created new SIP headers, and submitted them for endorsement to the IETF.
Some extensions were accepted, as they were deemed to be useful to all types of SIP implementations. Others, related to e.g. user authentication, QoS, or charging were harder to swallow and led to very harsh discussions. Most of these extensions are directly related to the fact that, unlike the Internet, IMS is a network of privately owned networks, whose usage is supposed to involve money exchanges.
Between 3GPP, which wanted to have IETF RFCs for all IMS SIP extensions, and IETF hardliners, the following compromise was found: the questionable IMS SIP extensions would be specified in IETF RFCs, but they would have a specific "proprietary" status, meaning that their usage is not recommended for general SIP usage. These headers are easy to recognize, as their name starts with "P-".
These P- headers do not threaten end-to-end interworking with non-IMS clients:
- Many of them are used between IMS network entities, and are invisible to IMS or SIP endpoints
- Some might be visible to non-IMS endpoints, but the endpoint does not absolutely need to understand them
- Gateways between IMS and the Internet may perform relevant SIP adaptations, if needed.
IMS specifications explicitly support session setup with non IMS endpoints
In order to offer a user experience that matches the one in a circuit switched network for a voice or video session, IMS adopted a session setup model which is more complex than the basic IETF SIP one. This extended session set up is also possible in the Internet, as it does not make use of any 3GPP-specific extension, but it is only optional and may not be supported by all SIP clients.
3GPP then started a study to address the issue of interworking between IMS-compliant clients and clients that would not support the optional features required by IMS session setup. This resulted in the requirement specified in chapter 5.4.2 of TS 23.228 named "Interworking with Internet" that an IMS client (or a user agent in the network acting on its behalf) must be able to fall back to basic SIP session setup procedures, if the peer cannot support the IMS-required extensions.
IMS Communication Services
In the course of its Release 7, 3GPP defined the concept of "communication service". I will not describe it here, but it is enough to say that some of the requirements associated to Communication Services could possibly lead to the creation of IMS walled garden services.
In order to avert this risk, the following requirements were added to the concept:
- The usage of communication service identifiers shall not adversely affect interoperability between IMS networks and interoperability with external SIP networks and CS networks
- The usage of communication service identifiers shall not restrict the inherent capabilities of SIP.
All IMS enablers rely on IETF specifications, and can be implemented in the Internet
This might need to be emphasized.
There is not such a thing as an IMS-specific presence, IMS-specific conferencing or IMS-specific messaging. These enablers and services are implemented in IMS with a specific service architecture, but the protocol(s) and data model(s) used are standard IETF ones.
A small issue is that, thanks to OMA or 3GPP, some IMS services may be associated with explicit OMA or 3GPP names (feature tags) transported in SIP signalling. For instance, IMS messaging as currently specified in OMA makes use of an OMA specific feature tag. This might require some simple SIP adaptation between IMS and non-IMS networks, or the understanding of IMS-specific feature tags by non-IMS client, but this is a minor thing. In any case, I hope that the industry will eventually realize that these OMA/3GPP names should not even exist.
A small issue is that, thanks to OMA or 3GPP, some IMS services may be associated with explicit OMA or 3GPP names (feature tags) transported in SIP signalling. For instance, IMS messaging as currently specified in OMA makes use of an OMA specific feature tag. This might require some simple SIP adaptation between IMS and non-IMS networks, or the understanding of IMS-specific feature tags by non-IMS client, but this is a minor thing. In any case, I hope that the industry will eventually realize that these OMA/3GPP names should not even exist.
Simple Addition of Protocol / Domain Gateways to IMS
The IMS service architecture makes very simple to deploy protocol converters and gateways, without the need for any specific standardization. Any SIP message originated from or addressed to a user can be routed to such a protocol converter/gateway through the user's service profile provisioned in the HSS. The message can then be routed to any domain using any protocol. Conversely, these converters/gateways can generate IMS-compliant signalling from anything they receive.
It is even possible for an IMS client to use non-SIP user addresses in its SIP messages. For instance, John may issue a SIP/IMS Instant Message towards Mary, whose IM service is not based on SIP and whose IM address is not a SIP or TEL URI. The IMS client could address the IM to e.g., foo:Mary. The address is not routable in an IMS network but this is not an issue. John's request is first routed to an IMS S-CSCF serving John. The S-CSCF then checks John's service profile. The important thing is that the network still not has checked if foo:Mary was an IMS-valid address. John's service profile may define that a request addressed to a user with an addressing scheme "foo:" should be routed to an IM gateway, which will take care of the rest. This is only after, if no gateway was accessed through John's service profile, that the S-CSCF would look into recipient's address, realize that there is a problem, and would therefore reject it.
Christophe
Subscribe to:
Posts (Atom)
Stumble It!
