[Sipping] Requirements for the identification of IMS communication services.

Hello All,

I am of the understanding that there have been some questions regarding
the requirements for the identification of IMS services.  I would like
to provide an understanding of the 3GPP discussions on this topic.  As I
see it, the need to identify the IMS communication services stems from
that we have/are devloping different services on IMS as a SIP
infrastructure, such as push-to-talk over cellular (PoC) or messaging.
As there are different services and as it is not safe to rely on the
expressed media as the media may be used in different services then
there is the need to identify the service that is requisted.  This could
be seen as a means to identify the context upon which to interpret the
SIP signalling.  This is required to e.g. Identify the application
server that supports this communication service and to identify the
client to invoke in the terminating network.  While writting this, I
seem to recall a parrallel discussion in relation to presence, and that
was along the lines that was that it was required to identify the
service that was used to communicate in the presence, as otherwise two
if the same presence information appeared for two incompatabile services
(e.g. two incomptable versions of push to talk) which fulfulled the same
end-user expectation appeared the same in presence, then the end-user
would get confused as to why s/he could communicate with some users but
not with others.

Please note that this is not intended to identify service that are
routed to, such as train time tables etc.  For these services, the
communication services is a means to route to and reach the ultimtate
end-user service.  This discussion is about how to identify the
communication service.

This has been discussed at an architectural level within 3GPP and a
Technical Report has been produced.  The Technical report can be found
at http://www.3gpp.org/ftp/Specs/Latest-drafts/23816-110.zip.  This has
been moved to approved status this week.  The essence of this technical
report has been included in specification text which can be captured in
http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_50_Budapest/Docs/S2-060468
.ZIP and
http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_50_Budapest/Docs/S2-060469
.ZIP .  Note that the changes included in S2-060468.ZIP are changes to
what was already included in the specification text last year.  These
documents represent the approved requirements within 3GPP.

I can appreciate that a number of readers prefer to read this in text
instead of word, as such the approved 3GPP text that has been included
in the specifications is included below.  As such, the text below are
the 3GPP stage 2 representation of the requirements.  It is worth
keeping in mind that the text below represensts archtectural
requirements and not the protocol realisation of these requirements.

Please don't hesitate to contact me if you have any questions.

I apologies in advance to the references to the 3GPP interfaces, they
are retained as I though it was better to avoid modifying any of the
agreed text when copying it into this email.

Best Regards,

Stephen Terrill

<Specification Text>
4.13.2	Identification of IMS communication Services
A communication service identifier provides a framework for the
identification of IMS communication services utilising the IMS enablers.
An IMS communication service is provided via the use of the IMS
enablers. At terminals, the use of a communication service identifier is
similar to the use of the port concept in TCP/IP, in that it allows
applications in a terminal and the network that use SIP for
communication purposes to be identified. In the terminal this means
dispatching a SIP message to the correct application, and in the network
it means selection of the correct application server over ISC. Examples
of IMS based applications and communication services are OMA messaging
and OMA PoC.
The communication service is an aggregation of one or several media
components and the service logic managing the aggregation, represented
in the protocols used. Its behaviour and characteristics may be
standardized as done for the two examples above, or proprietary and
specific for e.g. an operator or an enterprise.
A service description specifies this behaviour and states e.g. the
allowed media combinations and state transitions as a consequence of
signalling and use of IMS enablers in the network and terminals.
The need of applying a service identifier is to be taken within the
specification of each individual service.
The communication service identifier identifies IMS communication
services and shall be included in the relevant SIP methods.

The IMS communication service identifier shall fulfil the following
requirements:
1. It shall be possible for the UE and an Application Server (AS) to set
the
   IMS communication service identifier in a SIP request, e.g. in the
   REGISTER and INVITE request.
2. Based on operator policy the S-CSCF or an AS shall be able to
validate an
   IMS communication service identifier in a SIP request. This includes
e.g.
   to check the syntactical correctness of a service identifier, and
policing
   the usage of a communication service identifier.
3. It shall be possible, e.g. for the UE, S-CSCF and AS, to identify an
   IMS service uniquely by the IMS communication service identifier.
4. It shall be possible for the S-CSCF to invoke appropriate service
   logic based on the IMS communication service identifier contained
   in a SIP request, e.g. route a SIP request containing a service
identifier
   based on initial filter criteria to the correct AS.
5. It shall be possible for the UE to invoke appropriate application
   based on the IMS communication service identifier contained in a
   received SIP request.
6. It shall be possible for the UE to indicate its service capabilities 
   to the network, e.g. during registration, using the 
   IMS communication service identifier.
7. The structure of the IMS communication service identifier shall be as

   simple as possible, i.e. the IMS communication service identifier
shall 
   be limited to identify a service.
8. Based on operator policy S-CSCF and AS shall consider the 
   IMS communication service identifier for online and offline charging,

   e.g. put appropriate data into call detailed records.
9. The communication service identifier shall be capable of being an 
   input into the policy control and charging rules.
10. It shall be possible to use the IMS communication service identifier
as 
    a means to authorise whether a subscriber is allowed to initiate or 
    receive request for a communication service.
11. The communication service identifier shall be taken into account 
    when selecting the correct UE(s), if multiple UEs are registered 
    for the same Public User Identity(s).
12. The usage of communication service identifiers shall not adversely 
    affect interoperability between IMS networks and interoperability 
    with external SIP networks and CS networks. The behaviour of a
network 
    receiving the IMS requests without an IMS communication service 
    identifier is a matter of operator policy. Usage of communication 
    service identifiers shall not decrease the level of interoperability

    with networks and UEs that are unaware of the communication service
identifier.
13. It shall be possible for the IMS network and UE to support
communications 
    that do not use a communication service identifier. In the case that
an 
    IMS communication service identifier is not present then the network
may 
    assume a particular IMS communication service.
14. The usage of communication service identifiers shall not restrict
the inherent 
    capabilities of SIP.
15. The usage of communication service identifiers shall not require
additional user 
    interaction, i .e. the communication service identifier is assumed 
    to be "added" by the UE that initiates the communication.

The network and the terminal shall be able to continue operation as
defined in 3GPP Release 5 and 3GPP Release 6.

The communication service identifier shall be available at least in the
following interfaces:
-	ISC; Gm; Mi, Mj, Mk, Mw; Mg; Mr;
-	Cx; Dx (e.g as part of the iFC);
-	Rx;
-	Rf, Ro.

NOTE:	The communication service identifier does not replace the 
public service identity (PSI). The communication service identifier
would be used to indicate the communication service used to access the
service addressed via a PSI, and is required to identify the
communication service even when SIP requests are sent towards another
entity without using a PSI.

4.13.2	Identification of IMS applications

An IMS application is an application that uses an IMS communication
service(s) in order to provide a specific service to the end-user.  The
IMS application uses specific IMS Communication Service(s) and provides
the end user service through the reuse of the SIP communication part of
service. The IMS application does not extend the definition of the IMS
communication service.  The IMS application reference identifies the
application utilising the IMS communication service.

<< removed figure >>

Figure 4.13-1:  IMS applications on top of an IMS communication service
The IMS application reference is used to identify the IMS applications
other than the default for the IMS communication service.  The IMS
application reference has significance at the UE and the SIP AS behaving
as SIP endpoints.  The means to transport the IMS application reference
is defined within the IMS communication services.  When used, it shall
be possible to transport the IMS application reference on at least on
the following interfaces:
*	ISC; Gm; Mi, Mj, Mk, Mw; Mg; Mr; Ro, Rx, Rf

</Specification Text>