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

From: "Stephen Terrill \(E2/EEM\)" <[email-masked]>
Date: Thu, 16 Mar 2006 13:42:54 +0100

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>

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 16 Mar 2006 15:11:09 +0200

Folks,

as you can see from the email below, 3GPP would like to know our 
position regarding the type of service identifier described in the 
documents pointed out by Stephen.

I know that some individuals have opinions on this issue. Therefore, I 
would like to have mailing list discussions on it. If needed, we will 
continue such discussions during the SIPPING session on Friday.

Thanks,

Gonzalo
SIPPING co-chair

Stephen Terrill (E2/EEM) wrote:
> 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 
> 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 
>    simple as possible, i.e. the IMS communication service identifier shall
> 10. It shall be possible to use the IMS communication service identifier as
>     with external SIP networks and CS networks. The behaviour of a network
>     that do not use a communication service identifier. In the case that an
>     to be “added” by the UE that initiates the communication.
> 
> •       ISC; Gm; Mi, Mj, Mk, Mw; Mg; Mr; Ro, Rx, Rf
> 
> 
> </Specification Text>
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Mar 2006 09:41:48 -0500

Steve,

I think we are trying to understand the role of a service identifier in 
a context more broadly applicable than IMS. It would help if you could 
explain this in some way that doesn't appear to simply facilitate MITM 
attacks. I guess this is motivated as a way to control the IMS ISC 
interface. It may be necessary to render that model, or some abstraction 
of it, as a framework in a requirements draft in the siping wg. The 
trick is to find some model that doesn't violate sip principles and norms.

	Paul

Stephen Terrill (E2/EEM) wrote:
> ------------------------------------------------------------------------
>

---

From: "Dale R. Worley" <[email-masked]>
Date: Thu, 16 Mar 2006 10:53:25 -0500

On Thu, 2006-03-16 at 13:42 +0100, Stephen Terrill (E2/EEM) wrote

I'm having some difficulty understanding this essay.  I understand the
words, but I'm clearly not understanding the *philosophy* of what IMS is
attempting to do.

I think this passage is an example:

> 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.

To my mind, if there are two incompatible implementations of push-to-
talk, then (of necessity), one is not standard-compliant, as all of the
SIP standards have been architected to provide interoperability.  And
when a device that supports some extension attempts to communicate with
a device that does not, a lot of thought has been put into making the
outcome be the best possible in the circumstance.

Whereas the 3GPP people seem to think of a set of "services", and any
communication must be tagged as which "service" it is using.  But this
(in effect) splits SIP into a whole host of incompatible mini-SIPs, each
of which is supported by the mini-Internet of SIP devices that
participate in that "service".

Dale

---

From: "Arjun Roychowdhury" <[email-masked]>
Date: Fri, 17 Mar 2006 14:06:43 -0500

Stephen,
Some comments:

It seems the gist of the motivation is that the PSI is not sufficient
to 'categorize' a particular service and apply policy on it (for
example, a PSI of [email-masked] says nothing about whether it is
an audio, or video or even if "conf=conference")

That I understand. However, I am trying to understand the root effect
of why this needs to be inserted in the SIP signalling path:

When is this 'service category identifier' really needed ?

a) For a service client (say UE) to 'locate' a particular service
b) For the IMS-Core to check if a particular AS will be allowed to
host its services in the network (say, the operator wishes to bar some
type of services)
c) For the P/S-CSCF to apply  a particular policy to a particular policy (type)
d) For online/offline charging CDRs to specify the category so some
billing solution could potentially apply differentiated charging based
on type

For case a) - the location of a service seems to be better handled by
protocols which handle this, like SLP (RFC 2608)

b) Is usually a configuration exercise by the operator - an AS will be
introduced only if it is a service the operator wants to introduce in
the first place.

c) For this case, the HSS provides a mechanism where an IMS
subscription is linked to multiple service profiles and each service
profile has PSIs as well as filter criteria.

Now, when a new service is introduced, by an application server,
referring to RFC 3087 (Control of Service Context using SIP
Request-URI), each URI should really specify the context of a service,
which as I understand it, is what the PSI is.
The person who applies a policy to a service is the operator of the
network, and that operator knows that
'sip:audio-conference.carrier.com' is an audio conference and
'sip:video-conference.carrer.com' is a video conference and this
should really be two PSIs. Since the operator knows this, it can apply
policies directly to the PSI without needing an explicit signaling
identification of the service type.

d) For d, again, each AS (in addition to IMS-core) generates CDRs
towards the CCF, so the charging policies can be associated according
to the PSI.

So in conclusion, I cannot think of cases why this category is really needed.

regds
arjun

On 3/16/06, Stephen Terrill (E2/EEM) <[email-masked]> wrote:
>
>
> 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.

<snip>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Mar 2006 10:52:47 -0500

Here are my thoughts on this topic.

Firstly, you are correct that there is a fairly extensive discussion on 
this topic in terms of presence. I'd strongly suggest that folks take a 
look at:

http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-data-model-07.txt

and in particular, Section 3.3 on Services and Section 3.3.2, which 
describes Reach Information. I'll quote three paragraphs that are 
particularly relevant to this discussion:

>  It is difficult to give a precise definition for service.  One
>    reasonable approach is to model each software or hardware agent in
>    the system as a service.  If a user starts a softphone application on
>    their PC, then that represents a service.  If a user has a videophone
>    device, then that represents another service.  This is effectively a
>    physical view of services.  This definition, however, starts to fall
>    apart when a service is spread across multiple software agents or
>    devices.  For example, a SIP URI representing an address-of-record
>    can be routed to a softphone or a videophone, or both.  In that case,
>    one might attempt instead to define a service based on its address on
>    the network.  This definition also falls apart when modeling devices
>    or applications that receive calls and dispatch them to different
>    "helpers" based on potentially complex logic.  For example, a
>    cellular telephone might house multiple SIP applications, each of
>    which can "register" different handlers based on the method or even
>    body type of the request.  Each of those applications or handlers can
>    rightfully be considered a service, but it doesn't have an address on
>    the network distinct from the others.
> 
>    Because of this inherent difficulty in precisely defining a service,
>    the data model doesn't try to constrain what can be considered a
>    service.  Rather, anything can be considered a service so long as it
>    exhibits a set of key properties defined by this model.  In
>    particular, Each service is associated with characteristics which
>    identify the nature and capabilities of that service, with reach
>    information that indicates how to connect to the service, with status
>    information representing the state of that service, and relative
>    information that describes the ways in which that service relates to
>    others associated with the presentity.
> 
>    As a consequence, in this model, services are not explicitly
>    enumerated.  There is no central registry where one finds identifiers
>    for each service.  Consequently, each service does not have a single
>    "service" attribute with values such as "ptt" or "telephony".  That
>    doesnt mean that these consolidated monikers aren't useful; indeed,
>    they represent an essential summary of what the service is.  Such
>    summarization is useful in creating icons that allow a user to choose
>    one service over another. 

Regardless of whether you use presence or not, the discussion and 
guidance here are directly applicable to this topic.

They key takeaway is that there are many dangers to interoperability 
associated with the explicit enumeration of services; they require 
global definition and agreement, and they result in (when taken to the 
extreme), a separation of SIP communications into multiple parallel, 
non-interoperable SIP networks, one for each vendor or service providers 
definition of what the service is. I believe others have commented on 
this within this thread. Nothing would be a greater crime to global 
interoperability for 3gpp to define a service called 'voip' and then 
require that only calls tagged with this service be processed and routed 
to the 'voip' client on each phone. This would inhibit the ability of 
clients outside of 3gpp to ever communicate with 3gpp endpoints, and 
that is something I am sure we all want to avoid.

That said, the text above recognizes that there are cases where you need 
to reach a specific instance of software in an endpoint because the 
communications is in the context of that application, and is truly 
meangingless outside of it. One example is voice communications that are 
part of a multiplayer game, where the voice is in concert with non-sip 
protocols that facilitate the game. In such a case, when I start a game, 
and try and connect with another user, unless that user is also running 
the game software, the voice communications should not take place. It 
would be non-sensical to connect to, for example, a regular telephone or 
voice-capable softphone that lacks the game.

The presence data model recognizes this, but strongly recommends that 
the URI itself be distinct for each of these. Distinct URI are readily 
obtained through presence. Each presence document would have a number of 
'tuples', each of which identifies a unique service. Each unique service 
has a unique service URI, which represents the mechanism I use to 
contact someone for that service. In the case of the game, the ideal 
solution is that I, in invoking this game, would subscribe to the 
presence of sip:[email-masked], get back their presence, find the one 
matching the game I'm interested in, and the select that URI. All of 
that can happen automatically.

The data model further states that there are cases where the URI cannot 
be used as a unique identifier for services, and indeed it calls out the 
use case of a cellular phone, which is the exact case I believe you are 
worried about. In that case, it recommends tecnologies like caller prefs 
for this purpose. However, I will restate an important sentence in the 
above:

>  Since the reach
>    information has to be understood in order for the service to be
>    utilized, reach information beyond the URI should be defined and used
>    sparingly. 

With an emphasis on SPARINGLY.

Your text below has me quite worried that these guidelines are not being 
adequately followed, and that will result in substantial 
interoperability problems.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Mar 2006 11:14:09 -0500

I strongly support what Jonathan says.

A concern of mine is that the word "service" is very generic. While 
there is some overlap between the ietf and 3gpp communities, it isn't 
enough to ensure that the two have the same definition of "service". I 
have a strong suspicion that they have *different* notions of what a 
service is. I have been trying to get a clear understanding of the ims 
notion of service, but so far I don't think I have done so.

If 3gpp shares the notion of service that Jonathan is talking about then 
his comments apply directly. If not, then we have more work to do.

	Paul

Jonathan Rosenberg wrote:
>> 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 
>> 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.
>>
>> 1. It shall be possible for the UE and an Application Server (AS) to 
>> set the
>>    IMS communication service identifier in a SIP request. This 
>> includes e.g.
>>     with networks and UEs that are unaware of the communication 
>> service identifier.
>>     IMS communication service identifier is not present then the 
>> network may
>> The communication service identifier shall be available at least in 
>> 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:
>>