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:39 +0100

Hi Paul,

Thanks for your comments.

Firstly, in response to the *one* application server concern that you
raised below - I certainly agree with that concern, I personally think
that can be improved, however that would be the subject of another
discussion.

As a clarification to the types of services - PTT (PoC), is of course an
obvious one.  I understand that there is seperate activities for
Messaging as a different services; and of course there is multimedia
telephony, and of course the medias could overlap. The signalling
procedurs assocuated with PTT are different from the ones that are used
with multimedia telephony.  I wouldn't say that 3GPP has said we should
have an identifier value for all of these. 

I will think more about the MITM attack view.

Best Regards,

Stephen.

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, March 20, 2006 4:14 AM
To: Stephen Terrill (E2/EEM)
Cc: sipping; Rohan Mahy; Gonzalo Camarillo (JO/LMF); Dean Willis
Subject: Re: [Sipping] Requirements for the identification of IMS
communication services.

Steve,

Comments inline.

	Paul

Stephen Terrill (E2/EEM) wrote:
> Hi Paul,
> 
> That seems like a useful discussion (though I understand that you are 
> all busy preparing for Dallas next week).
> 
> Could you help me by elaborating more on the MITM attacks that you 
> envisage?

There is a perception in a significant portion of the ietf sip community
that the kind of agressive insertion of active components in the
signaling path that IMS does *is* a MITM attack. This is especially the
case when the purpose of those is to enforce the will of the provider
even when that is not in the best interests of the end user.

If possible, it would be good if you could explain what you want in a
way that doesn't support that view.

> You are correct that one aspect of this is a way to control the IMS 
> ISC interface, in order to be able to locate the correct application 
> server that should assist with the communication.

It concerns me when you say things like "locate *the* correct
application server", because that implies there is exactly *one*. I am
still concerned with the view that services are mutually exclusive,
rather than complementary and additive. For instance, I see PTT as
conceptually just a particular style of floor control of a voice medium.

  I see similar, or not so similar, kinds of things as applicable to
other media - video, IM, etc. And I see no reason why they shouldn't
coexist in a single call.

Ultimately you do need to choose *one* UE to terminate the call. If
multiple UEs have differing capabilities and none is a perfect match for
what the caller wants then compromises need to be made. I suppose the
same *may* be true of intermediate servers. But if so I think this needs
to be considered that way rather than ignoring that anyone would *want*
more than one "service".

And so far PTT (POC) is the only example of a service I am aware of. It
is really hard for me to extrapolate from one data point to a general
concept.

> There is another aspect to
> this, and that is the terminating device - the idea is that the 
> terminating device should be also be able to understand which logic in

> the terminal is required to be invoked for an incomming SIP session.  
> A

The part in the terminating UE is the easiest part to deal with. While I
am still waiting to understand better what services are, I imagine that
callerprefs provides plenty of capability to make choices like this,
even in the presence of multiple requirements and capabilities.

It however is far from perfect. It is particularly silent on how to
reconcile the preferences of the caller with those of the callee. And
the matching algorithms are complex and not well understood. But even
so, the complexity is the result of trying to satisfy a lot of
requirements, so I hesitate to set out on a quest for a different
mechanism without careful consideration.

> third aspect is this is policy in general.  There may be different 
> policy for different services.  One example of this, is that for the 
> same media (say voice), the policy of how to prioritise the transport 
> of this media in the network may differ depending on the service - as 
> in if the voice was using for telephony, maybe one priority would 
> apply, but if it was used in the context of push-to-talk, another 
> policy may apply
> (Note: only an example).

Why should this kind of decision be based on the sip session as a whole?

This seems to be a per-media thing. You are saying "we gods in the
middle of the network will decide what combinations of things make
sense, and you subjects will just have live with that". If I am entitled
to various priorities, perhaps with differing billing algorithms, then
why can't those be combined in a single call?

> I wonder whether the ISC routing could also be modelled as network 
> policy from the sipping wg perspective?

Yes, there is ongoing work on end-to-middle policy that may well be
applicable here. I have not been following it in detail, but I think it
could provide much more flexibility than just providing a single name
for the complete set of policy decisions that need to be made. It would
be good to bring the experts on that into the discussion.

	Paul

> Best Regards,
> 
> ..//Steve
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, March 16, 2006 3:42 PM
> To: Stephen Terrill (E2/EEM)
> Cc: sipping; Rohan Mahy; Gonzalo Camarillo (JO/LMF); Dean Willis
> Subject: Re: [Sipping] Requirements for the identification of IMS 
> communication services.
> 
> 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:
> 
>>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-060
> 46
> 8.ZIP_
> 
>>and
>>
> 
> _http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_50_Budapest/Docs/S2-060
> 46
> 9.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
> 
> 

_______________________________________________
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