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

From: "Stephen Terrill \(E2/EEM\)" <[email-masked]>
Date: Mon, 20 Mar 2006 19:27:50 +0100

Hello Arjun,

Thank-you for your comments.

Before addressing your comments directly, I would like to raise one
aspect that may make this clearer first - and that is that this also
applies to communication between two uses.  We need to be able to apply
policy, link in the correct SIP application servers in the network that
support the communication.  Take, for example, that we have some sort
network based "accept" list or "reject" list in the network for
multimedia telephony communication.  In that example, the call will be
destined for the B-user, and not a PSI.  We still need to be able to
apply the policy, link in the correct applicatoin server etc. 

When communicating to a service addressed by a URI (such as a PSI as you
pointed out), then there is still the need to invoke the network work
based AS, apply policy on the means to communication, not necessarily on
the service addressed as an endpoint.  For example, for voice, the voice
used with Push-to-talk may have a different policy treatment than the
voice used in multimedia telephony.

Please see below.

Best Regards,

Stephen Terriill.

-----Original Message-----
From: Arjun Roychowdhury [mailto:[email-masked]] 
Sent: Friday, March 17, 2006 8:07 PM
To: Stephen Terrill (E2/EEM)
Cc: sipping
Subject: Re: [Sipping] Requirements for the identification of IMS
communication services.

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)
<Stephen>
Agree
</Stephen>

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.
<Stephen>
For the services address as an end-point as per a PSI as you point out,
i agree.  However, there is still the need to introduce the SIP-Ass that
are used to support the ongoing communication between the terminal and
the SIP application server addressed by the URI.
</Stephen>

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.
<Stephen>
For the routing policy, I agree that the HSS provides a mechanism to
link in appliction services specific for the user.  However, that does
require that it has the correct information in order to work.  The
identifier that identifiers the IMS communication service would assist
with that greatly.

There is also policy applied at the P-CSCF, which is used to authorise
the use of the radio resources in a cellular access.  This (so far) has
nothing to do with the HSS information, and may differ depedending on
the communication service (not the service addressed by the URI)..
</Stephen>

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>

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Mar 2006 19:24:42 -0500

> apply the policy, link in the correct applicatoin server etc. 

There is still the implied mutual exclusion in this that I find 
distressing. Why can't the policy be applied if/when a particular 
capability is used within a session, rather than permitting the session 
based on an assertion that it will use exactly one capability and then 
blocking any attempt to use a different capability?

	Paul